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

Необработанные уведомления (Сервис)

Если вы, в качестве типа push-уведомления используете wns/raw, полезные данные, включенные в уведомление могут быть чем угодно, а не только XML, но их размер не может превышать 5 Кб.

Конечно, Windows не может непосредственно что-либо сделать с этими данными, таким образом приложение должно предоставить обработчик для приёма этих уведомлений, как рассказано в следующем разделе.

Приём уведомлений (приложение)

Выполняющееся приложение принимает push-уведомление посредством PushNotificationChannel.onpushnotificationreceived. Это, опять же, нужно для обработки полезной информации из wns/raw уведомлений, но может использоваться и для других видов уведомлений. Если приложение не исполняется, то, конечно, оно не может принять это событие. Вместо этого, приложение должно присуствовать на экране блокировки с фоновой задачей PushNotificationTrigger, предназначенной для этой цели (смотрите "Задачи, зависимые от экрана блокировки и триггеры" ниже в этой лекции). Этот код затем принимает полезные данные XML, обрабатывает их и отправляет, при необходимости, либо обновления плиток, либо индикаторов событий, либо всплывающие уведомления. Помимо сохранения некоторых данных в папки данных приложения, это, на самом деле, всё, что могут делать фоновые задачи, но этого достаточно для сохранения ощущения динамичности приложений и для приглашения пользователей к запуску приложений.

В выполняющемся приложения вызывается событие pushnotificationreceived так же для других типов уведомлений. Сценарий 3 примера показывает это в его обработчике событий – я, для упрощения, слегка изменил этот код:

function startListening() {
 // Предполагаем, что канал получен и проверен
 channel.addEventListener("pushnotificationreceived", pushNotificationReceivedHandler);
 }
 function pushNotificationReceivedHandler(e) {
 // Извлекаем полезные данные уведомления для каждого типа уведомлений

 var notificationPayload;
 switch (e.notificationType) {
 case pushNotifications.PushNotificationType.toast:
 notificationPayload = e.toastNotification.content.getXml();
 break;

 case pushNotifications.PushNotificationType.tile: notificationPayload = e.tileNotification.content.getXml(); break;

 case pushNotifications.PushNotificationType.badge:
 notificationPayload = e.badgeNotification.content.getXml();
 break;

 case pushNotifications.PushNotificationType.raw:
 notificationPayload = e.rawNotification.content;
 break;
 }

 // Обработка уведомления: установите e.cancel в true для подавления автоматической обработки.
 }

Последняя часть в вышеприведенных комментариях важна. Когда вы принимаете событие в исполняющемся приложении, не нужно показывать всплывающее уведомление, только если оно не имеет отношения к какой-то части приложения, которая сейчас невидима. Например, если у вас есть приложение, которое работает и с электронной почтой и с календарём, вам захочется сделать видимыми всплывающие уведомления об электронной почте, когда пользователь видит календарь, и уведомления о событиях календаря, когда он работает с электронной почтой. В данном случаае установка e.cancel в true не позволит отобразиться всплывающему уведомлению.

В событии ) для того, чтобы узнать подробности об этом.

Советы по отладке

При использовании push-уведомлений, практика показывает, что если уведомления не доставляются на устройство, обычно это не из-за проблемы с WNS. Вот списко того, что надо проверить (Спасибо Гансу Андерсену за этот список):

Windows Azure Toolkit и Windows Azure Mobile Services

Очевидно, много работы нужно для создания службы, которая может принимать URI канала и отправлять уведомления через WNS. Признавая это, Windows Azure Toolkit (http://watwindows8.codeplex.com/) снова предлагает некоторые решения. Рассмотрение всех подробностей выходит за рамки этого курса, но ссылки ниже помогут вам начать с этим разрибаться. В частности, "Пример уведомлений Azure" (http://watwindows8.codeplex.com/wikipage?title=Notifications%20Sample%20%E2%80%93%20C%23%20and%20JavaScript) и "Пример о необработанных уведомлениях" (http://watwindows8.codeplex.com/wikipage?title=Raw%20Notifications%20Sample), так же "Пример рабочего процесса push-уведомлений" (http://watwindows8.codeplex.com/wikipage?title=Push%20Notification%20Worker%20SamplereferringTitle=Documentation). Вот полезное видео на сайте Channel 9: "Эпизод 73 – Ник Харрис о push-уведомлениях для Windows 8" (http://channel9.msdn.com/Shows/Cloud+Cover/Episode-73-Nick-Harris-on-Push-Notifications-for-Windows-8). Дополнительные ресурсы, весьма вероятно, будут опубликованы после того, как была написана эта лекция, поэтому поиск в Интернете позволит вам найти больше материалов.

Кроме того, посмотрите на "Мобильные сервисы Windows Azure" (http://www.windowsazure.com/en-us/develop/mobile/?fb=ru-ru), которые помогут вам создать масштабируемую серверную часть приложения, в том числе – структурированные облачные данные, проверку подлинности, и push-уведомления. Этот новые сервисы, на момент написания, поэтому у меня нет ссылок на другие ресурсы, но, совершенно очевидно, их стоит изучить.

Фоновые задачи и приложения экрана блокировки

В конце введения к этой лекции я рассказывал, как все, о чём мы говорили до сих пор помогает "создать динамичную, интерактивную среду в то время, как приложения часто не исполняются или могут запускать лишь небольшие фрагменты кода". Сейчас наша тема будет посвящена этой последней фразе – запуску небольших фрагментов кода с помощью фоновых задач. Как описано выше, фоновые задачи связаны с экраном блокировки, так как приложения, которым разрешено работать на экране блокировки должны так же задействовать определенные фоновые задачи.

Позвольте мне повторить здесь, что мы уже видели ряд сценариев, где пользователь может ожидать некоторой деятельности, связанной с приложением без необходимости запуска приложения. Периодические обновления плиток, push-уведомления, запланированные всплывающие уведомления и даже передача данных через контракт Общий доступ производят полезную деятельность , когда приложение приостановлено или не исполняется. Приложения так же могут настраивать фоновую передачу данных, которая выполняется, когда приложение не запущено, как мы увидим в Главе 3. А возможность фонового воспроизведения музыки предоставлена для специального класса приложений, которым нужно выполняться для поддержки сеансов связи VoIP, воспроизведения аудио, онлайновых бесед и так далее.

Что нам осталось рассмотреть – так это те самые небольшие фрагменты кода приложения, которые Windows может запускать в ответ на различные триггеры. Триггеры, в некоторых случаях, могут подвергнуться дальнейшей настройке в соответствии с дополнительными условиями, в итоге фоновая задача исполняется только тогда, когда в этом есть реальная необходимость. Всё это делается для уменьшения количества фоновой деятельности, которая истощает батареи устройства. Некоторые типы триггеров, на самом деле, требуют, чтобы пользователь поместил приложение на экран блокировки для того, чтобы преднамеренно ограничить количество приложений, которые могут реагировать на эти триггеры. Более того, Windows так же ограничивает процессорное время, которое могут потреблять подобные фоновые задачи:

Использование сетевого соединения так же ограничено в связи с затратами энергии батарей. Что это за ограничение, я не могу точно сказать, так как система анализирует использование энергии более пристально, нежели количество переданной информации. Средства оценки предела можно найти в материале "Поддержка приложения с помощью фоновых задач" (http://msdn.microsoft.com/library/windows/apps/hh977046.aspx). (Пока мы говорим об этом, вам, возможно, будет интересно посмотреть "Руководство и контрольный список для фоновых задач" (http://msdn.microsoft.com/library/windows/apps/Hh977043.aspx), документ "Введение в фоновые задачи" ( http://www.microsoft.com/en-us/download/details.aspx?displaylang=enid=27411), и материал "Поддержание производительности при работе приложения в фоновом режиме — фоновые задачи" (http://blogs.msdn.com/b/windowsappdev_ru/archive/2012/06/01/10313828.aspx) в блоге для разработчиков приложений для Windows 8).

Возможно, вы подумали: "Ничего себе! Разве Windows 8 на самом деле имеет подобные ограничения?".

Коротко говоря – да, так как Windows не только стремится сэкономить энергию батарей для приложений переднего плана, с которыми работает пользователь, но так же она стремится к тому, чтобы от приложений переднего плана у пользователя остались бы наилучшие впечатления. Это подразумевает, что система не хочет столкнуться с фоновыми приложениями, которые, если им это позволить, занимают столько ресурсов, сколько смогут. (Разработчики фоновых служб всегда найдут оправдание для захвата ресурсов!).

Возможно, вы попадали в такую ситуацию, когда вы запускаете приложение, но его запуск занимает целую вечность, так как некие таинственные службы интенсивно используют жёсткий диск, передают данные по сети, нагружают процессор и так далее. Я, например, в подобной ситуации разбираюсь в чём дело, с помощью Диспетчера задач и Монитора ресурсов, после чего останавливаю любой процесс, который пожирает ресурсы моей системы – и будь что будет. Именно возникновения подобных впечатлений у пользователя и пытается избежать Windows 8.

"Хорошо", - скажете вы (при условии, что я, в некоторой степени, вас убедил), - "Означает ли это, что нет способа для выполнения некоторой фоновой работы наподобие индексирования данных, создания экскизов изображения, обработки видео и так далее?".

На самом деле, есть способы для того, чтобы это сделать. Во-первых, когда приложение находится на переднем плане, оно может делать подобные вещи в любых объёмах, так как оно, в конечно счете, отвечает за то, какие впечатления у пользователя создаст взаимодействие с ним. (Приложения, написанные на JavaScript, могут для подобных целей, использовать рабочие веб-процессы для того, чтобы убрать выполнение подобных задач из потока пользовательского интерфейса, а так же – передавать задачи компонентам WinRT, которые выполняют их дела в других потока и асинхронно возвращают результат. Мы ознакомимся с этим в Главе 5.).

Во-вторых, когда устройство подключено к сети переменного тока, а не работает от батарей, Windows позволяет фоновым задачам, запущенным для обслуживания триггеров, работать по 15 минут или дольше (в зависимости от нужд приложения). Здесь всё еще применимы ограничения ресурсов процессора, которые они могут потреблять, но задачи, которые не задействуют пользовательский интерфейс, который не разрешено использовать фоновым задачам – могут выполнить несколько миллиардов инструций за одну или две секунду на гигагерцовом процессоре!

Что мы имеем в итоге, так это то, что существует три различных класса фоновых задач и связанных с ними триггеров:

В следующих разделах мы рассмотрим эти задачи подробнее, но сначала поговорим о некоторых общих их чертах: об объявлении фоновых задач в манифесте, об общем процессе работы с задачами с помощью WinRT, и о некоторых условиях

Фоновые задачи в манифесте

Все фоновые задачи для приложения объявляются в манифесте, где каждое объявление указывает на тип задачи и на код, который должен исполняться для выполнения этой задачи, как показано на рис 6.1. Мы видели этот раздел манифеста в Главе 4 курса "Пользовательский интерфейс приложений для Windows 8, созданных с использованием HTML, CSS и JavaScript", где мы выбирали пункт Звук (Audio) для приложения, которое воспроизводит в фоновом режиме музыку. Что касается других параметров, то Системное событие (System Event) используется для первых двух классов вышеперечисленных задач, опции Канал управления (Control Channel), Таймер (Timer) и Push-уведомления (Push Notification) предназначены для задач, которые связаны с приложениями экрана блокировки.

Во всех случаях, поле Начальная страница (Start Page) – это то место, где вы указываете JavaScript-файл, который будет исполняться для этой задачи независимо от приложения, передавая ему информацию лишь через папки данных приложения, вы, на самом деле, можете использовать здесь любой язык, какой хотите. Учитывая квоты на процессорное время, написание фоновых задач на языке вроде C++ или C# позволит вам выполнять некоторые задачи более эффективно, и в подобном случае вы будете использовать поле Точка входа (Point field )(если задача реализована в виде DLL, которая находится в пакете приложения), и, возможно, поле Исполняемый файл (Executable) (если задача реализована с помощью EXE-файла, который так же расположен в пакете приложения) для идентификации кода модуля и конкретной функции для вызова.

Полезно отметить, что даже хотя в поле Начальная страница (Start Page) для JavaScript ожидается указание страницы, там, на самом деле, может быть лишь код для фоновой задачи – вы получите ошибку, если попытаетесь задать в этом поле HTML-файл. (Для того, чтобы говорить точнее, фоновые задачи на JavaScript – это рабочие веб-процессы, простые и понятные). А почему фоновые задачи не могут отображать пользовательский интерфейс, так это потому, что Windows не загрузит HTML или CSS-код, лишь JavaScript! Таким образом, отправляя обновления плиток, индикаторов событий и всплывающие уведомления – это все дела, связанные с пользовательским интерфейсом, которые могут выполнять фоновые задачи. Для выполнения чего-то другого, фоновая задача должна записать некоторое значение в папку данных приложения, а это значение должно, с помощью обработчиков событий для фоновых задач, получить и обработать основное приложение, что мы скоро увидим.

Вы можете заметить, что параметр Системное событие (System Event) в редакторе манифеста не предусматривает поля, где вы можете задать триггер для задачи. Это выполняется в коде, при создании задачи, как мы увидим в ближайшее время.

Создание и регистрация фоновой задачи

Объявление фоновой задачи в манифесте – это лишь объявление, которое сообщает системе о том, что приложение намеревается использовать фоновую задачу. Приложение должно зарегистрировать фоновую задачу из кода для того, чтобы она могла исполняться, что реализуется с помощью ) (его родительское пространство имен содержит всё, к чему мы будем обращаться в контексте фоновых задач). Проще говоря, вы создаете экземпляр средства для создания фоновой задачи, задаёте его свойства name и taskEntryPoint, вызываете его методы setTrigger и addCondition для указания того, когда следует запускать фоновую задачу, и затем вызываете register.

Обычный код для этого можно найти в примере "Фоновая задача" (http://code.msdn.microsoft.com/windowsapps/Background-Task-Sample-9209ade9), в js/global.js.

Этот модуль объявляет глобальный объект BackgroundTaskSample, который содержит свойства и методы. Нас здесь интересует метод, который называется registerBackgroundTask, он регистрирует заданную точку входа (имя JavaScript-файла или имя класса в C#, Visual Basic, или C++), с заданным именем и применяет некоторые триггеры и условия.

var BackgroundTaskSample = {
// Свойства, содержащие имена и точки входа для задач примера опущены

//
// Регистрация фоновой задачи с заданными taskEntryPoint, taskName, trigger,
// и condition (дополнительно).
//
"registerBackgroundTask": function (taskEntryPoint, taskName, trigger, condition) {
var builder = new Windows.ApplicationModel.Background.BackgroundTaskBuilder();

builder.name = taskName; builder.taskEntryPoint = taskEntryPoint; builder.setTrigger(trigger);

if (condition !== null) {
builder.addCondition(condition);
}

var task = builder.register(); BackgroundTaskSample.attachProgressAndCompletedHandlers(task);

// [Опущен код, отражающий особенности примера]

// Удаление предыдущего статуса завершения из локальных параметров.
var settings = Windows.Storage.ApplicationData.current.localSettings;
settings.values.remove(taskName);
},

В этом коде метод ), с помощью которого управляют зарегистрированной задачей. У зарегистрированной задачи есть свойство name и назначенное системой свойство taskId, последнее из них вы можете использовать для сохранения данных приложения, которые уникальны для задачи. Так же у него есть метод unregister, который вы можете вызвать для отмены регистрации, и два события: completed и progress. Обработчики для этих событий назначают обычным способом, с помощью addEventListener, как показано в функции BackgroundTaskSample.attachProgressAndCompletedHandlers в примере:

"attachProgressAndCompletedHandlers": function (task) {
 task.addEventListener("progress",
 new BackgroundTaskSample.progressHandler(task).onProgress);
 task.addEventListener("completed",
 new BackgroundTaskSample.completeHandler(task).onCompleted);
 },

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

Здесь присутствует одно статическое свойство, BackgroundTaskRegistration.allTasks, объект IMapView , с помощью которого вы можете получить свои зарегистрированные задачи и получить для каждого отдельный объект BackgroundTaskRegistration.

Очень важно отметить, что Windows позволяет регистрировать одну и ту же фоновую задачу дважды и присваивает уникальные значения taskId каждой из них, поэтому будьте осторожны, чтобы не столкнуться с дублированием задач. Обратите так же внимание на то, как вышеприведенный код registerBackgroundTask пользуется контейнером локальных параметров в данных приложения. Это – способ связи приложения с каждой из своих независимых задач, так как данные приложения – это единственное средство для обмена подобными данными.

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

Условия

Конкретные условия вы можете задать с помощью объекта ), который является экземпляром класса ). Фоновая задача, зарегистрированная с одним или большим количеством условий – каждый вызов addCondition приводит к добавлению очередного условия – будет запланирована к выполнению только если все условия выполняются.

Каждый экземпляр может иметь один из следующих типов, заданных в перечислении SystemConditionType: internetAvailable (интернет-подключение доступно), internetNotAvailable (интернет-подключение не доступно), sessionConnected (пользователь вошёл в систему), sessionDisconnected (пользователь вышел из системы), userPresent (пользователь в настоящий момент занят какими-то делами), и userNotPresent (пользователь ничего не делает некоторое время).

Очевидно, каждая пара из этих условий является взаимоисключающей: если вы зарегистрировали задачу с условиями internetAvailable и internetNotAvailable, Windows поймёт, что вы никогда не планируете, чтобы эта задача когда-нибудь запускалась, поэтому система оставит её сидеть на обочине и никогда не побеспокоит! С другой стороны, вы можете использовать эти условия для того, чтобы быть уверенным, что ваша задача выполняется только тогда, когда нужна. Если вам нужно запустить фоновую задачу, которая обновляет канал push-уведомлений, например, нет смысла этого делать при отсутствии подключения к Интернету. (В следующем разделе, "Задачи для триггеров обслуживания", мы увидим пример). С другой стороны, если у вас есть фоновая задача, исполнение которой никогда не должно совпадать с активной работой пользователя, вы можете добавить условие userNotPresent.

Обратите внимание на то, что так как условие sessionDisconnected выполняется тогда, когда пользователь выходит из системы, оно полезно лишь для фоновых задач, которые используют экран блокировки.

Задачи для триггеров обслуживания

Фоновые задачи, использующие триггеры обслуживания, вероятно, являются наиболее общим типом задач – они содержат какой-либо код, который нужно периодически запускать, но только тогда, когда система подключена к источнику питания . Подобные задачи отлично подхдят для "проверки на что-либо", или для другой деятельности, которую нужно выполнять периодически, но при этом не важно – когда точно это произойдёт. Например, триггеры обслуживания не подходят для чего-то вроде синхронизации данных с сервером, так как это должно происходить своевременно, и это лучше будет реализовать с помощью API фоновой передачи данных, которое мы рассмотрим в Главе 3.

Триггер обслуживания – то, что вы передаете в ). При создании экземпляра предоставляют два параметра. Первый – это необходимый период обновления (свойство freshnessTime, в минутах), всегда следует использовать наибольший период, подходящий для конкретного сценария. Система будет всегда ожидать, как минимум, прохождения этого периода, перед первым запуском задачи. Второй параметр – это флаг, который указывает на то, нужно ли запустить задачу лишь один раз (свойство oneShot).

Сценарий 2 примера Push-уведомления и периодические уведомления, клиентская часть" (http://code.msdn.microsoft.com/windowsapps/Push-and-periodic-de225603) показывает использование триггера обслуживания для периодического обновления WNS-канала, как описано ранее в разделе "Запрос и кэширование UIR канала". Этот код взят из js/scenario2.js, некоторая его часть находится во внутренней функции, которая называется registerTask:

var background = Windows.ApplicationModel.Background;
  var pushNotificationsTaskName = "UpdateChannels";
  var maintenanceInterval = 10 * 24 * 60; // 10 дней

  var taskBuilder = new background.BackgroundTaskBuilder();
  var trigger = new background.MaintenanceTrigger(maintenanceInterval, false);
  taskBuilder.setTrigger(trigger);
  taskBuilder.taskEntryPoint = "js\\backgroundTask.js";
  taskBuilder.name = pushNotificationsTaskName;

  var internetCondition = new background.SystemCondition(background.SystemConditionType.internetAvailable);
  taskBuilder.addCondition(internetCondition);

  taskBuilder.register();

Так как срок действия URI канала – 30 дней, пример создаёт триггер, предназначенный для исполнения каждые 10 дней (10 дней * 24 часа в день * 60 минут в часе). Так же сюда разумно добавлено условие internetAvailable, так как не имеет смысла пытаться обновить URI канала, когда нет подключения к Интернету.

Саму задачу можно найти в файле примера js/backgroundTask.js, что отражено в свойстве taskEntryPoint:

(function () {
// Импорт вспомогательного объекта Notifier
importScripts("//Microsoft.WinJS.1.0/js/base.js");
importScripts("notifications.js");

var closeFunction = function () {
close();
};

var notifier = new SampleNotifications.Notifier();
notifier.renewAllAsync().done(closeFunction, closeFunction);
})();

Код задачи использует пару других скриптовых файла, importScripts, второй из которых, notifications.js, это набор вспомогательных функций образца для уведомлений, где renewAllAsync обновляет список, в котором находятся URI канала, ранее сохраненные приложением.

Важно. Вы так же можете заметить, что обработчики завершения и ошибки задаваемые в promise-объекте из функции ). Фоновые задачи в приложении, написанном на JavaScript, запускаются в областе видимости рабочего веб-процесса, таким образом, глобальная область в этом коде – это WorkerGlobalScope, а не window. Данный вызов позволяет убедиться в закрытии независимо работающей фоновой задачи и гарантирует, что ресурсы, которые были выделены для задачи, соответствующим образом освобождены.

Врезка: Экземпляр задачи и острочка фоновой задачи

В фоновой задаче JavaScript, Windows.UI.WebUI.WebUIBackgroundTaskInstance.current содержит объект WebUIBackgroundTaskInstanceRuntimeClass (http://msdn.microsoft.com/library/windows/apps/windows.ui.webui.webuibackgroundtaskinstanceruntimeclass.aspx), который предоставляет дополнительные сведения о выполняющейся задаче: её instanceId, связанный с ней объект BackgroundTaskRegistration в свойстве task, свойство progress, в котором задача может сохранить процентное значение степени её выполнения, флаг succeeded , который позволяет указать, что задача завершена, свойство suspendedСount (показывает, сколько раз был приостановлена задача при превышении ограничений), и событие canceled , которое сообщает о том, что задача будет закрыта.

Этот объект так же предоставляет метод getDeferral , который возвращает отложенный объект, метод completed которого вызывается, когда задача завершена. Как и всегда, вы используете откладывание операции, если вам нужно выполнить асинхронную операцию в фоновой задаче. Не забудьте всегда вызывать close, когда все действия будут выполнены.

Задачи для системных триггеров (не для экрана блокировки)

Следующий класс фоновых задача содержит следующие привязки к различным системным триггерам, в частности, экземпляры класса ). Объект триггера создают с помощью ключевого слова new и передают два параметра: значение SystemTriggerType value (доступное потом как свойство triggerType) и флаг логического типа oneShot. Эти триггеры могут работать независимо от экрана блокировки, они описаны в следующей таблице:

В примере "Фоновая задача" есть несколько примеров этих триггеров. В Сценарии 1, js/sample-background-task-with-condition.js, мы можем видеть использование триггера timeZoneChange и условия userPresent (здесь BackgroundTaskSample это вспомогательный объект из global.js):

BackgroundTaskSample.registerBackgroundTask(BackgroundTaskSample.sampleBackgroundTaskEntryPoint,
  BackgroundTaskSample.sampleBackgroundTaskWithConditionName,
  new Windows.ApplicationModel.Background.SystemTrigger(
  Windows.ApplicationModel.Background.SystemTriggerType.timeZoneChange, false),
  new Windows.ApplicationModel.Background.SystemCondition(
  Windows.ApplicationModel.Background.SystemConditionType.userPresent));

Это явно тот случай, когда я хотел бы использовать другую переменную для того, чтобы каждый раз не вводить обозначение пространства имен Windows.ApplicationModel.Background, но вы, по крайней мере, не ошибетесь, читая этот код! В любом случае, тот же пример, в Сценарии 4 и js/global.js, так же показывает использования триггера servicingComplete со вспомогательной функцией registerServicingCompleteTask, которая так же проверят, была ли задача уже зарегистрирована:

"registerServicingCompleteTask": function () {
// Проверяет, была ли уже зарегистрирована фоновая задача servicingComplete.
var iter =
Windows.ApplicationModel.Background.BackgroundTaskRegistration.allTasks.first();
var hascur = iter.hasCurrent;
while (hascur) {
var cur = iter.current.value;
if (cur.name === BackgroundTaskSample.servicingCompleteTaskName) { BackgroundTaskSample.updateBackgroundTaskStatus(
BackgroundTaskSample.servicingCompleteTaskName, true);
return;
}
hascur = iter.moveNext();
}

// Если эта фоновая задача еще не была зарегистрирована.
BackgroundTaskSample.registerBackgroundTask(
BackgroundTaskSample.servicingCompleteTaskEntryPoint,
BackgroundTaskSample.servicingCompleteTaskName,
new Windows.ApplicationModel.Background.SystemTrigger(
Windows.ApplicationModel.Background.SystemTriggerType.servicingComplete, false),
null);
},

В примере, задачи, связанные с данными триггерами, реализованы на C# в WinRT-компонентах, которые можно найти в проекте Tasks решения примера. Я не буду показывать здесь их код, так как мы посмотрим на стандартную структуру компонентов WinRT в Главе 5. Однако, это показывает, что мы можем использовать подход с применением разных языков для фоновых задача. В подобных случаях поле Точка входа (Entry Point) для задач в манифесте указывает на класс/метод C#, который реализует фоновую задачу, как, например, Tasks.ServicingComplete. Если вы перейдете на страницу примера "Фоновая задача" (http://code.msdn.microsoft.com/windowsapps/Background-Task-Sample-9209ade9), вы так же можете загрузить C# и C++-версии примеры для того, чтобы увидеть более структурные варианты.

Задачи, зависимые от экрана блокировки и триггеры

Последняя группа фоновых задач, это те, которые требуют, чтобы приложение было добавлено на экран блокировки. Для них существует четыре применимых опции ) (Таймер), ) (Push-уведомления), и ) (Канал управления). Они описаны в следующей таблице вместе с указанием доступных примеров, демонстрирующих их использование:

Примечание. В имитаторе Visual Studio работа с экраном блокировки не поддерживается. для отладки приложений экрана блокировки, вам нужно использовать опции отладки Локальный компьютер (Local Machine) или Удалённый компьютер (Remote Machine).

Фоновые задачи для этих триггеров создаются и регистрируются так, как мы уже видели. Например, TimeTrigger, создаётся с указанием интервалам freshnessTime (в минутах) и флага oneShot, как показано в Сценарии 5 примера "Фоновая задача" (js/time-trigger-background-task.js):

BackgroundTaskSample.registerBackgroundTask(
 BackgroundTaskSample.sampleBackgroundTaskEntryPoint,
 BackgroundTaskSample.timeTriggerTaskName,
 new Windows.ApplicationModel.Background.TimeTrigger(15, false), null);

) для того, чтобы позволить пользователю добавить навигационное приложение на экран блокировки, чтобы оно могло более последовательно отслеживать его перемещения. Вообще говоря, навигационное приложение обычно не особенно полезно на экране блокировки, преимущественно потому что оно не может показывать карту! Лучше, таким образом, использовать API Windows.System.Display.DisplayRequest для того, чтобы предотвратить отображение экрана блокировки.

Создание ), в Сценарии 1 (js/scenario1.js):

function registerBackgroundTask() {
// Регистрирует фоновую задачу для необработанных уведомлений
var taskBuilder = new background.BackgroundTaskBuilder();
var trigger = new background.PushNotificationTrigger();
taskBuilder.setTrigger(trigger);
taskBuilder.taskEntryPoint = sampleTaskEntryPoint;
taskBuilder.name = sampleTaskName;

var task = taskBuilder.register();
task.addEventListener("completed", backgroundTaskComplete);
}

Хотя и можно выполнить вызов . У приложения нет возможности этим управлять – всё, что оно может сделать, запросив соответствующие данные – это убедиться в том, что доступно для выбора пользователем в соответствующем разделе Настроек ПК (PC Settings).

Запрос выполняется с помощью метода Windows.ApplicationModel.Background.BackgroundExecutionManager.requestAccessAsync; даннй вызов следует выполнить до регистрации фоновой задачи (снова смотрите Сценарий 5 примера "Фоновая задача"):

Windows.ApplicationModel.Background.BackgroundExecutionManager.requestAccessAsync();

Когда этот вызов осуществляется впервые, он вызывает окно для получения согласия пользователя, которое показано на рис 6.2. Если пользователь выбирает вариант Разрешить (Allow), приложение появится в соответствующем разделе Параметров ПК (PC Settings) в качестве опции для добавления на начальный экран, в противном случае этого не произойдет. Как и в случае с другими разрешениями, пользователи могут изменять свое мнение позже, воспользовавшись настройками Разрешений (Permissions), как показано на рис 6.3.

Для того, чтобы увидеть полную демонстрацию, обратитесь к примеру "Приложения экрана блокировки" (http://code.msdn.microsoft.com/windowsapps/Lock-screen-apps-sample-9843dc3a). В Сценарии 1 он показываеть, как запрашивать доступ к экрану блокировки и проверять результат – значение из перечисления BackgroundAccessStatus (http://msdn.microsoft.com/library/windows/apps/windows.applicationmodel.background.backgroundaccessstatus.aspx). Он так же показываеть выполнение запросов и отключение этого доступа с помощью методов getAccessStatus и removeAccess объекта BackgroundExecutionManager.

Сценарий 2, в свою очередь, показывает отправку уведомлений индикатора событий на экран блокировки, вместе с обновлением текста около часов, если приложение выбрано для отображения этого текста. Здесь нет ничего особенного, если речь идёт об экране блокировки: подобные обновления происходят точно так же, как и для плитки приложения. Разница лишь в том, что эти обновления отображаются на экране блокировки. В случае с индикаторами событий, глиф уведомления отображается вместе с изображением, которое задает параметр Эмблема (Badge Logo), заданный в разделе Интерфейс приложения > Уведомления (Application UI > Notifications) манифеста (рис 6.1). Повторяя из ранее упомянутого, это изображение может иметь лишь белые и прозрачные пиксели и должно быть представлено в трех размерах для разного уровня масштабирования: 24x24 (100%), 33x33 (140%), и 43x43 (180%).

Сценарий 3, наконец, показывает, как добавить дополнительные плитки на экран блокировки, независимо от плитки приложения. Для того чтобы дополнительная плитка была доступна для экрана блокировки, подразумевая, что приложение уже запросило доступ к экрану блокировки, вам нужно установить следующие два свойства объекта ), которые мы как-то упоминали: lockScreenBadgeLogo и lockScreenDisplayBadgeAndTileText. Если дополнительная плитка присутствует на начальном экране, эти свойства так же делают её доступной на странице Параметров ПК (PC Settings) для экрана блокировки.

Отладка фоновых задач

К данному моменту вы уже, возможно, запустили фоновую задачу TimeTrigger в Сценарии 5 примера "Фоновые задачи", и хотя с того времени прошло уже больше 15 минут (может быть больше 30 минут, если вы просто пропустили 15-минутное окно, когда таймеры объединились), вы, возможно, всё еще ждете, пока пройдёт этот период. Значит ли это, что ваша жизнь при отладке фоновых задач будет состоять из сплошного ожидания?

К счастью, ответ на этот вопрос – "Нет" и "Возможно". То есть, отладчик Visual Studio знает о зарегистрированных фоновых задачах и предоставляет их список в выпадающем меню Приостановить (Suspend) на панели инструментов:

Выбор одной из этих команд немедленно вызовет фоновую задачу, так что вам не придется ждать или пытаться активировать триггер по-настоящему. Первое предостережение заключается в том, что если свойство триггера oneShot установлено в true и он уже был вызван, снова он вызван не будет. Второе предостережение заключается в том, что если вы запускаете JavaScript-приложение с фоновыми задачами, написанными на других языках, вам нужно изменить тип отладчика для основного проекта приложения с Только скрипт (Script Only) на Управляемый (Managed) или Машинный (Native), как показано ниже, иначе вы не сможете устанавливать точки останова в модулях, написанных на других языках.

Третье предостережение заключается в том, что фоновые задачи, которые используют ControlChannelTrigger, PushNotificationTrigger, и SystemTriggerType.SmsReceived не отображаются в вышеупомянутом меню Visual Studio.

Таким образом, может возникнуть необходимость воспользоваться проверенными методами вывода диагностических данных для того, чтобы понять, что происходит с вашей задачей и наблюдать за событиями в Просмотре событий (Event Viewer) на предмет ошибок при активации. Подробнее об этих методах можно узнать в материале "Отладка фоновой задачи" (http://msdn.microsoft.com/library/windows/apps/jj542415.aspx).

И, наконец, еще раз отмечу, что фоновые задачи не поддерживаются в имитаторе Visual Studio, как и динамические плитки, уведомления и многие другие механизмы, упомянутые в этой лекции. Вам нужно использовать, вместо этого, опции Локальный компьютер (Local Machine) или Удалённый компьютер (Remote Machine).

Что мы только что изучили (Ух ты!)