Плитки, уведомления, экран блокировки и фоновые задачи

Активация приложения с помощью дополнительной плитки

Дополнительные плитки предоставляют способ активации приложения с переводом в состояние, которое отличается от состояния по умолчанию. Это похоже на то, как аргументы командной строки работают с классическими приложениями рабочего стола или с консольными программами. Этот процесс полностью зависит от содержимого свойства arguments дополнительной плитки. Когда пользователь касается дополнительной плитки или щелкает по ней мышью, вызывается событие приложения activated с видом активации launch и со значением свойства дополнительной плитки arguments в eventArgs.detail.arguments. Затем приложение предпринимает действия, предписываемые этими данными, такие, как перемещение на конкретную страницу содержимого, получение фрагмента содержимого из онлайнового источника и так далее. В примере о дополнительных плитках, код активации в файле js/default.js перемещается к странице Сценария 5, мы передаем arguments как параметр для WinJS.Navigation.navigate:

function activated(eventObject) {
if (eventObject.detail.kind ===
Windows.ApplicationModel.Activation.ActivationKind.launch) {
if (eventObject.detail.arguments !== "") {
// Аргументы активации присутствуют (они заданы, когда
// дополнительная плитка была закреплена)
eventObject.setPromise(WinJS.UI.processAll().done(function () {
// Перемещение к странице Scenario 5, где пользователю будут показаны
// аргументы активации
return WinJS.Navigation.navigate(scenarios[4].url, eventObject.detail.arguments);
}));
} else {
// Активация по умолчанию
}
}
}
    

Элемент управления страницы (js/LaunchedFromSecondaryTile.js) принимает строку аргументов в параметре options и для метода processed и для метода ready. В примере эта строка просто выводится на экран:

var page = WinJS.UI.Pages.define("/html/LaunchedFromSecondaryTile.html", {
processed: function (element, options) {
if (options) {
document.getElementById("launchedFromSecondaryTileOutput").innerHTML += "
  " + "App was activated from a secondary tile with the following activation" +
  "arguments : " + options + "
     ";
}
},
ready: function (element, options) {
});
    

Ваше собственно приложение, конечно, будет делать с arguments что-нибудь гораздо более интересное!

Управление дополнительными плитками

В дополнение к методам и свойствам для создания дополнительных плиток, класс SecondaryTile имеет два статических метода для управления дополнительными плитками приложения:

exists ( http://msdn.microsoft.com/library/windows/apps/windows.ui.startscreen.secondarytile.exists.aspx) Возвращает логическое значение, показывающее существует ли на Начальном экране дополнительная плитка, идентифицируемая ее свойством tileId. Это сообщает вам о том, заменит ли метод requestCreate*, вызванный с тем же самы tileId существующую плитку другой. Это показано в Сценарии 4 примера о дополнительных плитках.

) Возвращает вектор объектов SecondaryTile, созданных приложением. Этот список включает в себя и плитки, перемещенные с другого устройства (они создаются с помощью опции copyOnDeployment) . Это показано в Сценарии 3 примера.

В дополнение, есть и несколько методов для работы с конкретным экземпляром SecondaryTile:

Если вы внимательно читали этот раздел, вы могли заметить, что я еще не упоминал Сценарий 6 примера. Это потому, что он показывает, как сделать дополнительную плитку динамической плиткой с возможностью обновления. Для того, чтобы это понять, нам нужно разобраться с обновлениями, так как используемый механизм обновлений сходен для всех плиток. Это будет следующей нашей темой. – я так и планировал!

Основы обновлений плиток

Локальное обновление для плитки, как было описано выше в этой лекции, это обновление, которое приложение выполняет, когда оно исполняется. На самом деле, это один из лучших моментов для отправки обновлений, так как весьма вероятно, что у приложения уже есть информация для обновления любых своих плиток. Во множестве случаев, особенно, когда приложение не связано с веб-сервисом, информация, нужная для динамических плиток приложения доступна лишь во время исполнения программы. Игра, например, может отправить обновления, показывающие лучшие результаты, новые соревнования, сведения о прохождении игры и другие виды интригующих приглашений, побуждающих пользователя снова запустить приложение. (Должен отметить, что лично для меня это отлично работает с игрой Fruit Ninja.)

Процесс отправки локального обновления плитки довольно прост, он использует API в пространстве имен Windows.UI.Notifications:

Совет. Если вы отправляете обновления или другие уведомления, когда ваше приложение исполняется, подумайте о том, чтобы отправлять обновления и в обработчике события resuming, если вы не собираетесь использовать другие средства, наподобие периодических обновлений или push-уведомлений для обновления плитки. С тех пор, когда приложение было приостановлено, может пройти немало времени, поэтому возобновление работы приложения – это хорошая возможность для отправки обновлений.

Обратимся теперь к примеру "Плитки и индикаторы событий приложения" ( http://code.msdn.microsoft.com/windowsapps/App-tiles-and-badges-sample-5fc49148) для того, чтобы увидеть, как обновления выглядят в коде. Так как имитатор Visual Studio не поддерживает динамические плитки и всплывающие уведомления, не забудьте запустить пример с опциями Локальный компьютер (Local Machine) или Удаленный компьютер (Remote Machine).

Предполагая, что у нас есть XMLDocument с обновлением в переменной tileXml, отправка обновления занимает лишь две строчки кода (смотрите js/sendTextTile.js):

var tileNotification = new Windows.UI.Notifications.TileNotification(tileXml);
Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication()
.update(tileNotification);
    

Похожим образом выглядит обновление дополнительных плиток в Сценарии 6 примера "Дополнительные плитки" (js/SecondaryTileNotification.js):

var tileNotification = new Windows.UI.Notifications.TileNotification(tileXml);
Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForSecondaryTile(
"SecondaryTile.LiveTile").update(tileNotification);
    

Гораздо более интересный вопрос заключается в том, как мы создаем переменную tileXml, содержащую полезные данные, в первом случае. Этот процесс включает в себя использование одного из предопределенных визуальных шаблонов плитки, и затем выбор метода для создания XMLDocument. Тогда мы увидим, как использовать изображения при обновлениях, а так же, как применять рекомендацию по брендированию. Локализация и обеспечение доступности – это дополнительные соображения, касающиеся обновления плиток, но мы вернемся к этим темам в Главе 6.

Выбор шаблона плитки

Первый шаг в создании обновления плитки заключается в выборе подходящего шаблона из "Каталога шаблонов плиток" ( http://msdn.microsoft.com/library/windows/apps/hh761491.aspx). Здесь вы найдете описания, изображения и XML для 10 доступных квадратных шаблонов и 36 прямоугольных шаблонов. Да, всего 46 разных шаблонов (надеюсь, вы понимаете, почему я не показываю здесь их все!). Некоторые – только текстовые, некоторые – графические, некоторые и с текстом и с изображением (только для прямоугольных плиток), и здесь представлено множество шаблонов, называемых обзорными (peek) шаблонами. Эти шаблоны, если вы на них взглянете на вышеупомянутой странице , составлены из двух частей, каждая из которых имеет размер всей плитки, как показано ниже для квадратной плитки (слева) и прямоугольной (справа):

С помощью обзорных шаблонов вы можете показать вдвое больше содержимого, чем с помощью ругих. Когда обзорное обновление отображается на динамической плитке, верхняя часть появляется сразу, и затем плитка переворачивается, или дает вам возможность "взглянуть" на нижнюю часть, и затем снова переключается на верхнюю часть, после чего динамическая плитка переключается к следующему обновлению в цикле, если оно есть (Приложение Travel (Путешествия) использует обзорные шаблоны, если вам нужен пример. Анимация, которая здесь применяется, похожа на WinJS.UI.Animation.createPeekAnimation.). Конечно, обе части должны содержать связанные данные, так как они являются частями единичного обновления.

По поводу макетов шаблонов есть несколько важных замечаний. Во-первых, во многих представленных в настоящее время шаблонах последняя строка текста не будет отображатья, если вы так же показываете на плитке логотип или короткое название (для предотвращения перекрытия). Вероятно, в будущем это изменится, но сейчас это так.

Во-вторых, изображения ограничены размером в 1024x1024 и максимальным размером в 200 Кб. Если любое изображение превышает данные лимиты, все обновление не будет отображено. Очевидно, лучше стараться не использовать большие изображения, если это возможно, так как подобные изображения лишь повышают уровень потребления памяти и возможную нагрузку на сеть (если выполняется загрузка изображения). Так же, для изображений на плитках, полезно принимать во внимание коэффициенты масштабирования 80%, 100%, 140%, и 180%. Однако, если вы не хотите работать с отдельными коэффициентами масштабирования, создайте изображение для плитки для масштаба в 180% и позвольте системе уменьшить его (здесь используется высококачественный алгоритм, поэтому изображение будет выглядеть так же хорошо, как если бы вы уменьшили его с помощью ПО для редактирования фотографий). Кроме того, для фотографий, рассмотрите использование JPEG вместо PNG, так как первый обладает лучшими возможностями по сжатию подобных изображений.

В-третьих, если вы работаете с изображениями, которые не соответствуют итоговому соотношению сторон, изображения будут масштабированы по ширине и обрезаны сверху и снизу. Отметим так же, что соотношение сторон прямоугольной плитки, не в точности 2:1. При 100% прямоугольная плитка имеет размеры 310x150 пикселей, что означает, что изображение, занимающее ее половину, будет иметь размеры в 155x150 пикселей (не вполне квадратное) и изображение в режиме просмотра коллекций (верхний правый угол правого изображения выше) будет 77.5x75.

В-четвертых, если вам нужна плитка с изображением и текстом, которые не вписываются в существующие шаблоны, вы всегда можете использовать графический шаблон, без текста (TileSquareImage и TileWideImage), в который можно поместить изображение, которое создается во время выполнения приложения. Однако, не придавайте плитке такой вид, будто она имеет отдельные кнопки или другие зоны нажатия: вся плитка всегда действует как неделимый объект для запуска приложения, поэтому подобный дизайн дезориентирует пользователя.

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

Сценарий 5 примера "Плитки и индикаторы событий приложения" показывает пример очень полезного дизайна и инструмента для экспериментирования с плитками, как показано на рис. 4.15. Эта часть примера скорее представляет собой инструмент, нежели код, который можно использовать в своем приложении. Его средства позволяют вам просто экспериментировать со всеми шаблонами и их содержимым, включая изображения, получаемые из локальных и удаленных источников, без необходимости каждый раз писать для этого код. Он так же позволяет вам испытать различные возможности брендинга приложений и отправки результата в качестве обновления на плитку примера на Начальном экране.

Создание полезных данных, Метод 1: заполнение содержимого шаблона

Первый способ создания полезных данных XML для заданного шаблона заключается в использовании метода ), которому вы передаете имя шаблона (значение из TileTemplateType (http://msdn.microsoft.com/library/windows/apps/windows.ui.notifications.tiletemplatetype.aspx )). Это показано в Сценарии 1 примера (js/sendTextTile.js):

function sendTileTextNotificationWithXmlManipulation() {
var tileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(
Windows.UI.Notifications.TileTemplateType.tileWideText03);

Этот метод возвращает объект XmlDocument, который содержит структуру XML для шаблона, но никакого содержимого. Если вы запустите пример и просмотрите tileXml сразу после вышеприведенного вызова, он будет содержать лишь следующее – элементы, но не данные:

<tile>
   <visual>
     <binding template="TileWideText03">
       <text id="1"></text>
     </binding>
   </visual>
 </tile>

Следующий шаг заключается в заполнении значений (в основном атрибутов) с использованием методов XmlDocument, которые вы уже, возможно, знаете (и они вам могут нравиться, а могут и нет):

var tileAttributes = tileXml.getElementsByTagName("text");
tileAttributes[0].appendChild(tileXml.createTextNode(
"Hello World! My very own tile notification"));

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

var squareTileXml = Windows.UI.Notifications.TileUpdateManager.getTemplateContent(
Windows.UI.Notifications.TileTemplateType.tileSquareText04);
var squareTileTextAttributes = squareTileXml.getElementsByTagName("text");
squareTileTextAttributes[0].appendChild(squareTileXml.createTextNode(
"Hello World! My very own tile notification"));

var node = tileXml.importNode(squareTileXml.getElementsByTagName("binding").item(0), true);
tileXml.getElementsByTagName("visual").item(0).appendChild(node);
Теперь все готово для того, чтобы отправить обновление плитке:
// отправка уведомления плитке приложения
Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication()
.update(tileNotification);
}

Отметим, что элементы visual в XML поддерживают version (версии) атрибутов, значение по умолчанию которых равняется 1. Это поможет поддерживать будущие изменения, где добавленные элементы с более новыми версиями XML, чем та, что сейчас поставляется в Windows 8, просто будут игнорироваться. Схему, которая применяется в плитках, если вам интересно, можно найти на странице "Схема плитки" ( http://msdn.microsoft.com/library/windows/apps/br212859.aspx).

Создание полезных данных, Метод 2: XML-строки

Вместо того, чтобы вызывать TileUpdateManager.getTemplateContent для получения XmlDocument с содержимым шаблона, вы просто можете создать нужный XmlDocument напрямую, из строки. Это очень похоже на создание элементов в DOM с помощью использования innerHTML вместо использования DOM API. Это предусматривает уменьшение общего количества вызываемых функций для создания необходимых полезных данных и хорошо подходит для предварительного задания большого количества почти полностью заполненых вариантов обновлений

Этот метод прост. Задайте XML-строку с содержимым для обновления, создайте новый XmlDocument, и воспользуйтесь его методом loadXml для превращения строки в полезные данные. В Сценарии 1 мы видим, как это реализуется для создания тех же полезных данных, что и в предыдущем разделе:

function sendTileTextNotificationWithStringManipulation() {
// создадим строку с XML-шаблоном плитки
var tileXmlString = "<tile>
  "
  + "<visual>
    "
    + "<binding template='TileWideText03'>
      "
      + "<text id='1'>Hello World! My very own tile notification</text>"
      + "
    </binding>"
    + "<binding template='TileSquareText04'>
      "
      + "<text id='1'>Hello World! My very own tile notification</text>"
      + "
    </binding>"
    + "
  </visual>"
  + "
</tile>";

var tileDOM = new Windows.Data.Xml.Dom.XmlDocument();
tileDOM.loadXml(tileXmlString); // Хорошая мысль – поместить это в блок try/catch

var tile = new Windows.UI.Notifications.TileNotification(tileDOM);
Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication()
.update(tile);
}

Очевидно, этот метод очень просто, но имеет недостаток, требуя ручной обработки. Кроме того, его сложнее отлаживать. (Поиск мелких ошибок в строках не относится к моему любимому времяпрепровождению!). К счастью, есть и еще один метод: Notifications Extensions Library, который предоставляет простоту использования строк с высоким уровнем надежности.

Создание полезных данных, Метод 3: Notifications Extensions Library

Третье средство создания необходимого XmlDocument для обновления плитки заключается в использовании того, что называется Notifications Extensions Library(Библиотека расширений уведомлений). Это WinRT-компонент, написанный на C#, который включен во многие примеры SDK, в том числе и в пример "Плитки и индикаторы событий приложения", который мы здесь рассматриваем. (Отметим, он включен в Ссылки (References) проекта.). Мы посмотрим на структуру подобных компонентов в Главе 5. Вероятнее всего эта библиотека в будущем войдет в состав Windows API, поэтому мы рекомендуем разработчикам использовать ее.

Библиотека упрощает заполнение шаблонов посредством свойств объекта, а не методов XmlDocument, и, так как она отлично протестирована в Microsoft, она гораздо более надежна, чем создание XmlDocument с использованием строк. Вот, как она используется в Сценарии 1 для создания, еще раз, тех же самых полезных данных, которые мы уже видели:

function sendTileTextNotification() {
 var tileContent =
 NotificationsExtensions.TileContent.TileContentFactory.createTileWideText03();
 tileContent.textHeadingWrap.text = "Hello World! My very own tile notification";

 var squareTileContent = NotificationsExtensions.TileContent.TileContentFactory
 .createTileSquareText04();
 squareTileContent.textBodyWrap.text = "Hello World! My very own tile notification";
 tileContent.squareContent = squareTileContent;

 Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication()
 .update(tileContent.createNotification());
 }

Проще говоря, объект библиотеки TileContentFactory предоставляет методы для создания объектов, эквивалентных XML-документам, предоставлеяемых TileUpdateManager.getTemplateContent. Как показано в вышеприведенном коде, эти объекты имеют свойства, эквивалентные каждому из полей шаблона и когда вы готовы передать данные в TileUpdater.update, вы просто вызываете метод createNotification.

Другая причина, по которой существует эта библиотека – это упрощение процесса создания ASP.NET веб-сервисов для периодических обновлений и push-уведомлений (где в уведомлении можно отправить обновление для плитки, обновления индикатора событий и всплывающие уведомления). Вместо создания полезных данных XML вручную – ненадежный и подверженный ошибкам подход – сервис может использовать Notifications Extensions Library для простого и последовательного создания XML для всех этих уведомлений.

Так как объектная модель библиотеки четко описывает XML, ей очень просто пользоваться. Вот еще один материал в документации на эту тему: "Краткое руководство: использование библиотеки ). И примеры, которые мы рассматриваем в этой лекции, показывают большинство вариантов ее использования.

Использование локальных изображений и изображений, полученных из веб

Сценарий 1 примера, как мы уже видели, показывает обновление плиток с использованием текста, но гораздо интереснее, когда в обновления входят и изображения. Они могут поступать либо из пакета приложения, локальных данных приложений, или из веб, с использованием, соответственно, таких URI, как ms-appx:///, ms-appdata:///local, и http://. Эти URI просто назначены атрибутам src элементов image в шаблонах плиток. (Это именно image, а не img, как в HTML). Снова отметим, что первые два URI обычно имеют три слэша в начале для указания на "текущее приложение". Для URI http:// требуется объявления в манифесте приложения возможности Интернет (Клиент) (Internet (Client)).

Сценарий 2 примера (js/sendLocalImage.js) показывает использование ms-appx:/// для изображения внутри пакета приложения, с вариантами для всех трех методов создания полезных данных, которые мы уже видели. При использовании методов XmlDocument, настройка источника изображения выглядит так:

  var tileImageAttributes = tileXml.getElementsByTagName("image");
    tileImageAttributes[0].setAttribute("src", "ms-appx:///images/redWide.png");
    Notifications Extensions Library дает нам свойства, которым мы можем присваивать URI:
    var tileContent = NotificationsExtensions.TileContent.TileContentFactory
    .createTileWideImageAndText01();
    tileContent.textCaptionWrap.text = "This tile notification uses ms-appx images";
    tileContent.image.src = "ms-appx:///images/redWide.png";

А при использовании XML-строк, вы можете включить URI напрямую в элемент image.

Сценарий 3 (js/sendWebImage.js) показывает то же самое, за исключением того, что вы можете использовать URI http://. Это хороший способ увидеть воздействие указания изображений, которые имеют различные соотношения сторон, как и тех, которые превышают разрешенные размеры в 1024 пикселя и размер файла в 200 Кб. Как вы можете увидеть, в подобных случаях обновления просто не отображаются.

Что касается URI ms-appdata:///local (перемещаемые и временные расположения не разрешены), его использование показано в Сценарии 8, где вы можете выбрать изображение с помощью средства выбора файлов и пример копирует его в папку локальных данных приложения. Затем на него, в составе полезных данных обновления, ссылаются как на файл, по URI ms-appdata:///local (js/imageprotocols.js):

    tileContent = NotificationsExtensions.TileContent.TileContentFactory.createTileWideImage();
    tileContent.image.src = "ms-appdata:///local/" + imageRelativePath;

Тот же сценарий позволяет вам экспериментировать с URI, указывающими на изображения в пакете и удаленные изображений, что позволяет реализовать инструментарий, представленный в Сценарии 5. Я так же обновил мое приложение "Here My Am!" для этой лекции (в материалах к лекции), добавил обзорный шаблон плитки с обновлением, которое содержит свежие изображения и расположения. Смотрите врезку "PNG против JPG" ниже.

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

Последняя возможность, касающаяся изображений, заключается в том, чтобы позволить Windows автоматически добавить строку запроса к URI http://. Эта строка запроса будет описывать текущий коэффициент масштабирования, параметры контрастности (для целей обеспечения доступности приложений), и языка. Это позволяет веб-сервисам соответствующим способом подготовить изображение, избавляя приложение от необходимости самостоятельно поддерживать все эти особенности. Как описано в материале "Схема плитки" ( http://msdn.microsoft.com/library/windows/apps/br212859.aspx), в особенности, для элемента image (http://msdn.microsoft.com/library/windows/apps/br230844.aspx ), эту опцию указывают, устанавливая атрибут addImageQuery элемента image в значение true (это так же поддерживается для элементов visual и binding):

    // Форма XmlDocument
    var tileImageAttributes = tileXml.getElementsByTagName("image");
    tileImageAttributes[0].setAttribute("addImageQuery", "true");

    // Форма XML-строки (другие строки кода опущены)
    var tileXmlString = /* ... */ "<image id='1' addImageQuery="true" src='ms-appx:///images/redWide.png'/>" /* ... */

    // При использовании Notifications Extensions Library (смотрите Сценарий 9 в примере)

    var tileContent = NotificationsExtensions.TileContent.TileContentFactory
    .createTileWideImageAndText01();
    tileContent.image.src = "ms-appx:///images/redWide.png";
    tileContent.image.addImageQuery = true;

Во всех этих случаях добавленная строка будет иметь такую форму:

?ms-scale=<scale>ms-contrast=<contrast>ms-lang=<language>

Здесь <scale> принимает значения 80, 100, 140, или 180, <contrast> принимает значения ), в том числе и то, как локализовать текст обновления.

Врезка: Размер файлов PNG против JPEG

Если говорить об изображениях для больших масштабов в 140% и 180%, кодировка, которую вы используете для изображений может оказать серьезное влияние и позволить, чтобы изображения не превысили лимит в 200 Кб. В Главе 3 курса "Введение в разработку приложений для Windows 8 с использованием HTML, CSS и JavaScript" мы видели, что прямоугольная широкая плитка при 180% масштабе занимает 558x270 пикселей, а квадратная – 270x270 пикселей. В случае с прямоугольной плиткой, обычная фотография в формате PNG легко превысит лимит в 200 Кб.

Я столкнулся с этим, когда добавлял в "Here My Am!" поддержку плитки, где я сделал уменьшенную версию текущего фотоснимка в папке локальных данных приложения и использовал URI ms-appdata:///local в полезных данных XML. Сначала я позаимствовал код из Сценария 10 примера "Плитки и индикаторы событий приложения", с которым мы здесь работали, для создания PNG-файла из элемента img с использованием временного canvas и API для работы с большими двоичными объектами. Все это хорошо работало для размера изображения плитки в 270х270 (для масштаба 180%, которое может быть уменьшено), но для размера в 558х270 файл оказался слишком большим. Тогда я взял код из Сценария 3 примера "Простая работа с изображениями" (http://code.msdn.microsoft.com/windowsapps/Simple-Imaging-Sample-a2dec2b0 ) для того, чтобы напрямую перекодировать StorageFile для текущего изображения в формат JPEG, где сжатие гораздо лучше и не нужно использовать временный canvas. Этот код находится в функции transcodeImageFile в pages/home/home.js, подпрограмма, которую мы перепишем в Главе 6 с использованием C# в компоненте WinRT.

Подобные соображения, безусловно, важны для сервисов, которые обрабатывают параметры addImageQuery для целей масштабирования. Для изображений больших размеров, возможно лучше всего остановиться на формате JPEG, для того, чтобы размер изображения оставался в пределах лимита в 200 Кб.

Брэндинг

Если вы – один из тех людей, кому нравится читать документацию по схемам XML (такую, как "Схема плитки" (http://msdn.microsoft.com/library/windows/apps/br212859.aspx ), о которой я недавно упоминал), вы могли заметить еще один атрибут для элементов visual и binding , который называется branding. Он может быть установлен в значения none, logo (по умолчанию), или name для указания того, следует ли поместить на плитку маленький значок компании или краткое имя, и то и другое описывается в манифесте приложения. Сценарий 5 примера "Плитки и индикаторы событий приложения" позволяет вам поэкспериментировать с этими вариантами.

Другие части манифеста, которые влияют на побновление плитки – это параметры Текст переднего плана (Foreground Text) и Цвет фона(Background Color) в разделе Интерфейс приложения (Application UI). Они определяют, как будет отображаться текст при всех обновлениях плитки (и всплывающие уведомления), и они не могут быть изменены в полезных данных плитки. Это позволяет сохранить однородность в брендировании приложения между обновлениями. Пользователь, вероятно, будет сбит с толку, если разные плитки одного и того же приложения будут иметь разные цвета.

В качестве быстрого примера, пример из SDK, с которым мы здесь работаем, использует светлый текст переднего плана и фоновый цвет #00b2f0. Если я перейду в Сценарий 5, выберу шаблон TileWideText09, добавлю немного текста и выберу значок (logo) для брендинга, (где маленький значок содержит изображение с надписью "SDK"), результат будет следующим:

Циклические и запланированные обновления, обновления со сроком действия

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

Для начала, вот возможность программной очистки всех обновлений и сброса плитки в ее состояние по умолчанию, соответствующему определению в манифесте. Это происходит при простом вызове TileUpdater.clear (показано в Сценарии 1):

 Windows.UI.Notifications.TileUpdateManager.createTileUpdaterForApplication().clear();

Следующая возможность, как уже упомянуто, это установка свойства TileNotification.expirationTime перед отправкой уведомления TileUpdater.update. Это гарантирует, что локальное уведомление будет автоматически удалено, и позволяет вам переопределять трехдневный период по умолчанию для обновлений, полученных из облака. Обновление появится немедленно (то есть, при следующем обновлении плитки) и затем будет удалено после того, как истечет его срок. Это показано в Сценарии 7 примера – отправка обновления с датой истечения срока действий приведет к отображению обновления, как на левом рисунке ниже. Когда срок истечет, обновление будет удалено, что приведет к тому, что плитка вернется в свое исходное состояние, как показано справа (и, да, я работаю над этим материалом в воскресенье вечером!):

Для того, чтобы отложить появление обновления до заданного времени, с истечением срока его действия или без него, нужно поступить немного иначе в самом начале: вместо создания объекта ) и откравить его ).

). Но, что на самом деле различается, так это то, что мы берем любой XmlDocument , который мы создали, наполнив его полезными данными с помощью любого из рассмотренных ранее, и создаем уведомление с указанием времени его доставки. Вот выборка из кода файла примера js/scenario1.js:

    // Пространство имен переменной
    var Notifications = Windows.UI.Notifications;

    // Задержка во времени доставки, взятая из элемента управления примера
    var dueTimeInSeconds = parseInt(document.getElementById("futureTimeBox").value);

    // Реальные дата и время доставки
    var currentTime = new Date();
    var dueTime = new Date(currentTime.getTime() + dueTimeInSeconds * 1000);

    // Здесь мы создаем XmlDocument в переменной tileDOM

    // Теперь создадим обновление с датой доставки
    var futureTile = new Notifications.ScheduledTileNotification(tileDOM, dueTime); 
    Notifications.TileUpdateManager.createTileUpdaterForApplication().addToSchedule(futureTile);

За исключением этих небольших изменений, все остальное, касающееся обновления плитки такое же, как раньше.

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

Что происходит, если вы запланируете серию обновлений, которые активизируются в одно и то же время? В примере "Запланированные обновления", например, отправьте серию обновлений плитки, которые должны произойти через 10 секунд и быстро пройдите на Начальный экран чтобы увидеть результаты. Эти обновления будут появляться одно за другим, и одно из них может быть потеряно, если другое запланировано вместе с ним. Как только будет выполнено последнее обновление, оно просто будет оставаться на месте до истечения, очистки плитки или поступления нового обновления.

В подобных случаях лучше будет пользоваться циклическим обновлением плитки с помощью нескольких обновлений, таким образом, плитка будет отображать больше, чем одно последнее обновление.

Динамические плитки поддерживают циклический показ до пяти обновлений, где длительностью каждого из них управляет система для того, чтобы сохранять единообразие на Начальном экране. Для того, чтобы включить эту возможность, сначала вы должны вызвать ), для того, чтобы отключить циклический показ уведомлений, его нужно вызвать с параметром false. Сама по себе очередь устроена по принципу "первый вошел – первый вышел (FIFO, вы не можете иным способом контролировать порядок показа обновлений), в итоге, самое старое уведомление удаляется, если добавляется новое, когда очередь содержит максимальное количество элементов. Другими словами, если вы активируете очередь и отправляют уведомления как обычно, пять самых свежих циклически отображаются на плитке.

Может возникнуть необходимость выборочно заменить присутствующие в очереди уведомления вместо того, чтобы полагаться на FIFO-поведение (или вызвать TileUpdater.clear и повторно отправить уведомления, которые вы хотите оставить). Это – цель свойства tag (тег) в TileNotification и ScheduledTileNotification. Свойство tag, повторюсь, это строка длиной до 16 символов, которая просто идентифицирует конкретное обновление. Если очередь включена, новое обновление с любым заданным параметром tag заменит любое обновление с тем же tag, уже присутствующее в очереди. Если такого тега в элементах очереди нет, обновление заменит самое старое в очереди. Таким образом, например, новостное приложение может иметь пять тегов для разных категорий новостей, таких, например, как world, local, politics, business, и health. Биржевое приложение, очевидно, может использовать теги для разных биржевых символов акций. Похожим образом, приложение, предоставляющее информацию о погоде может использовать теги обновлений в виде почтовых индексов или других идентификаторов расположения.

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

Обновления индикаторов событий

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

Индикаторы событий – это просто маленькие значки, глифы – число из одной-двух цифр, или один из некоторого количества символов, которые появляются на плитке вне зависимости от другой деятельности по ее обновлению. Они применяются для оповещения о состоянии приложения, а не для отображения некоторого содержимого, поэтому, наподобие названия или логотипа, они не анимируются вместе с другими обновлениями. Однако, изменения индикатора анимируются особым образом, с использованием WinJS.UI.Animations.updateBadge, как было кратко показано в Главе 5 курса "Пользовательский интерфейс приложений для Windows 8, созданных с использованием HTML, CSS и JavaScript".

То, как можно отправить индикаторы событий на плитку, по структуре напоминает обновление плитки. Начинают с создания полезной нагрузки для ), или с использованием Notifications Extensions Library, которая содержит полную поддержку индикаторов событий. В случае с индикаторами событий, это перебор, говорить об XML-"документе", так как он содержит лишь один элемент, badge, с одним атрибутом, value, для которого можно задать число – от 1 до 99 (все, что больше, отображается как 99+), или один из 11 специальных глифов, как показано ниже. Отметим, что хотя глифы показаны здесь на синем фоне, их реальный цвет зависит от Цвета фона (Background Color) в вашем манифесте:

Если хотите, можете использовать функцию ) для получения XmlDocument с подобным содержимым; на странице справки по этомуметоду есть пример кода, который показывает, как это сделать. Но, так как XML здесь очень простой, так же легко создать объект из строки, использовав команду new Windows.Data.Xml.Dom.XmlDocument , а потом вызвать метод loadXml, как мы уже видели в случае с плитками.В Notifications Extensions Library так же есть методы для этого и для выполнения обновлений. Оба подхода показаны в Сценарии 6 примера "Плитки и индикаторы событий приложения".

Как бы вы ни создали нужный объект, следующий шаг заключается в создании экземпляра BadgeNotification ( http://msdn.microsoft.com/library/windows/apps/windows.ui.notifications.badgenotification.aspx) с этим XmlDocument:

   var badge = new Windows.UI.Notifications.BadgeNotification(badgeDOM);

Этот объект уведомления так же, как и в случае с плитками, поддерживает свойство expirationTime. Помимо этого, последний шаг заключается в вызове ) для получения ) для плитки приложения, или – вы вполне можете это предсказать - ) для получения BadgeUpdater для дополнительной плитки с заданным tileId. После того, как вы получите BadgeNotification (повторюсь, здесь может помочь Notifications Extensions Library), затем вы вызываете BadgeUpdate.update:

  Windows.UI.Notifications.BadgeUpdateManager.createBadgeUpdaterForApplication()
    .update(badge);

Или:

      Windows.UI.Notifications.BadgeUpdateManager.createBadgeUpdaterForSecondaryTile
      ( "SecondaryTile.LiveTile").update(badge); 

Как и при работе с плитками, BadgeUpdater.clear полностью убирает индикатор уведомлений, что эквивалентно отправке обновления со значением none. Вот и все.

Помимо этого, класс BadgeUpdater имеет два дополнительных метода, startPeriodicUpdate и stopPeriodicUpdate, которые присутствуют и в классе TileUpdater. А не знакомы ли они вам? Периодические обновления – это наша следующая тема, - да, я и это запланировал!

Врезка: Сколько сетевого трафика нужно плиткам?

Вместе с многими другими улучшениями, Task Manager (Диспетчер задач) для Windows 8 умеет отслеживать объем данных, переданных приложениями по сети для обновления плитки. Запустите Диспетчер задач, не забудьте нажать на кнопку More Details (Подробнее) в его нижней левой части, и затем выберите вкладку App History (Журнал приложений). Объем сетевого трафика, потребленный для обновления плиток показан в самой правой колонке. Здесь обычно отображаются маленькие значения, но это параметр, благодаря которому вы можете увидеть, не чрезмерны ли эти обновления.