Командный пользовательский интерфейс

Отображение, скрытие, включение и обновление команд

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

appbar.getCommandById("cmdAdd").disabled = true;

Позвольте мне повторить, что команды, которые появляются на панели приложения, уникальны для каждой страницы. Нет необходимости пытаться поддерживать неизменную структуру панели приложения для всех страниц. Таким образом, если команды не нужны на какой-либо странице, не беспокойтесь о том, чтобы их отображать. Что важнее, так это то, постоянный состав панели приложения для отдельно взятой страницы, так как это по-настоящему неудачная идея – появляющиеся и исчезающие команды, зависящие от состояния страницы. Это приведет к тому, что пользователи будут размышлять о том, как привести страницу в нужное состояние для того, чтобы появились какие-либо команды!

Говоря об изменениях, вполне допустимо изменять или обновлять команды во время выполнения программы, что может устранить необходимость создания множества команд, которые вы можете поочередно показывать или скрывать. Так как каждая команда в панели приложения – это лишь DOM-элемент, вы можете, на самом деле, выполнять любые изменения, какие хотите, в любое время. Пример этого показан в Сценарии 3 примера, где панель приложения изначально создается с кнопкой Play (html/custom-icons.html):

<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'cmdPlay', label:'Play', icon:'play', tooltip:'Play this song'}">
</button>
 

Обработчик события click этой кнопки использует функцию doCluckPlay в js/custom-icons.js для переключения между состояниями:

var isPaused = true;

function doClickPlay() {
var cmd = document.getElementById('cmdPlay');

if (!isPaused) {
isPaused = true; // поставлено на паузу cmd.winControl.icon = 'play'; 
cmd.winControl.label = 'Play'; cmd.winControl.tooltip = 'Play this song';
} else {
isPaused = false; // проигрывается cmd.winControl.icon = 'pause'; 
cmd.winControl.label = 'Pause';
cmd.winControl.tooltip = 'Pause this song';
}
}
 

Вы можете использовать что-то подобное для закрепления или открепления дополнительных плиток (secondary tiles), как мы увидим в лекции 2 курса "Программная логика приложений для Windows 8, созданных с использованием HTML, CSS и JavaScript и их взаимодействие с системой". И, снова, кнопки – это лишь элементы в DOM и обновление любых их свойств, включая стили, обновит элемент на экране, как только вы вернете управление в поток пользовательского интерфейса.

Использование beforeshow для целей настройки команд, безусловно, эффективно, но вы можете достичь тех же результатов другими способами. Стратегия, которой вы пользуетесь, зависит от архитектуры вашего приложения и от ваших собственных предпочтений. С точки зрения пользователя, до тех пор, пока нужные команды доступны ему в нужное время, неважно, как это реализовано в программе!

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

Один из подходов заключается в том, чтобы каждая страница приложения объявляла и поддерживала собственную панель приложения, что подразумевает создание панелей приложения "на лету" в методе страниц ready. Это делает взаимодействие между содержимым страницы и панелью приложения весьма четким и ограниченным рамками страницы. Недостаток такого подхода заключается в том, что общие команды – те, которые появляются более чем на одной странице – приходится объявлять множество раз, что ухудшает возможности по управлению ими и способствует привлечению небольшой неоднородности, которая приходит как муравьи на сахар. Тем не менее, если содержимое разных страниц сильно отличается и у вас есть лишь несколько общих команд, такой подход может быть правильным выбором. Это, так же, необходимо, если ваша страница использует несколько страниц верхнего уровня, вместо одной страницы с элементом управления страницы, как мы обсуждали в лекции 3курса "Введение в разработку приложений для Windows 8 с использованием HTML, CSS и JavaScript", так как каждая HTML-страница верхнего уровня, в любом случае, должна объявить свою собственную панель приложения.

Для приложений, использующих элементы управления страниц, применяется другой подход, который заключается в объявлении одной панели приложения на странице верхнего уровня и в установке ее свойства command внутри метода ready каждого из подобных элементов управления. Недостатком здесь является то, что так как command – это свойство только для записи, вы не можете объявить общие команды в HTML и позже добавить команды, характерные для отдельной страницы, только если вы не идете сложным путем создания каждого отдельного дочернего элемента AppBar в каждом методе ready . Подобный код утомительно писать и поддерживать.

К счастью, есть и третий подход, который позволяет вам объявить одну панель приложения на странице верхнего уровня, которая содержит все необходимые команды, для всех страниц, и затем выборочно показывать определенные наборы таких команд в каждом из методов ready отдельных страниц. Это – цель существования методов панели приложения showCommands, hideCommands и showOnlyCommands .

Все эти методы прпнимают массив командных элементов, которые могут быть либо объектами AppBarCommand , либо id команд. Метод showCommands делает эти командные элементы управления видимыми и может быть вызван несколько раз с различными установками для получения итогового набора. С другой стороны, метод hideCommands скрывает заданные команды в панели приложения, опять же, с возможностью многократного вызова. Основы использования этих методов показаны в Сценарии 4 нашего примера.

Метод showOnlyCommands объединяет два вышеописанных метода, делая заданные команды видимыми и скрывая остальные. Если вы задаете панель приложения со всеми командами, вы можете использовать метод showOnlyCommands в методе ready каждой страницы для того, чтобы быстро и просто настроить вид панели приложения. Хитрость заключается в получении массива, подходящего для передачи в метод. Вы можете, конечно, вручную написать код для команд, занести данные в специальный массив, как в Сценарии 4 примера сделано для showCommands и hideCommands . Однако, если вы думаете, что это хороший пример Плохой идеи, то знайте, что я тоже так думаю! Использование подобного массива подразумевает, что любые изменения, которые вы вносите в панель приложения, должны произойти и в HTML-файле, и в JS-файле, а это означает, что любой, кто будет поддерживать ваш код в будущем, без сомнения, станет осыпать вас проклятиями!

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

Рассмотрим нижеприведенное определение панели приложения, где, для краткости, я опустил свойства вроде label, icon и section , так же, как и любые другие классы стилей:

<div id="appbar" data-win-control="WinJS.UI.AppBar" data-win-options="{
commands:[
{id:'home', extraClass: 'menuView gameView scoreView'},
{id:'play', extraClass: 'menuView gameView scoreView'},
{id:'rules', extraClass: 'menuView gameView scoreView'},
{id:'scores', extraClass: 'menuView gameView scoreView'},
{id:'newgame', extraClass: 'gameView gameSnapView'},
{id:'resetgame', extraClass: 'gameView gameSnapView'},
{id:'loadgame', extraClass: 'gameView gameSnapView'},
{id:'savegame', extraClass: 'gameView gameSnapView'},
{id:'hint', extraClass: 'gameView gameSnapView'},
{id:'timer', extraClass: 'gameView gameSnapView'},
{id:'pause', extraClass: 'gameView gameSnapView'},
{id:'home2', extraClass: 'gameSnapView'},
{id:'replaygame', extraClass: 'scoreView'},
{id:'resetscores', extraClass: 'scoreView'}
]}" >
</div >
 

В свойствах extraClass мы задаем четыре различных набора: menuView, gameView, gameSnapView, и scoreView. Когда все находится там, где нужно, простой вызов querySelectorAll предоставляет тот массив, который нам нужен для showOnlyCommands. Общая функция, наподобие следующей, может быть, затем, использована из метода ready каждой страницы (или из любого другого места) для активации командных элементов для нужного экрана программы:

function updateAppBar(view) {
var appbar = document.getElementById("appbar").winControl;
var commands = appbar.element.querySelectorAll(view);
appbar.showOnlyCommands(commands);
}	
 

При таком подходе, заслуга создания которого принадлежит моему колеге Джесси МакГата, панель приложения полностью определяется в едином месте, что серьезно упрощает управление ей и ее поддержку.

Стилизация панели приложения

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

Существуют семь классов WinJS для стилизации, которые используются панелью приложения, как описано в нижеприведенной таблице, где первые два применяются к панели приложения в целом, а другие пять – к отдельным командным элементам:

Подсказка. Для того чтобы помочь себе в настройке стилей панели приложения в Blend сделайте ее залипающей (sticky ), или добавьте вызов метода show в методе ready страницы, или в обработчике события activated . Это позволит сделать панель приложения видимой в Blend, работать с ней, в противном случае возникают сложностью с открытием панели в процессе разработки.

Обычно нет необходимости в прямом переопределении стилей win-appbar или win-commandlayout. Вместо этого следует создавать селекторы для пользовательских классов, связанных с этими стилями и затем стилизовать то, что вам нужно. Здесь можно использовать и псевдоселекторы, наподобие button:hover, button:active и так далее.

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

В качестве основы, Сценарии 2 (html/custom-color.html) добавляет CSS-класс customColor к панели приложения:

<div id="customColorAppBar" data-win-control="WinJS.UI.AppBar" class="customColor" ...> 

В css/custim-color.css он затем стилизует селекторы на основе .win-appbar.customColor. Следующие правила, например, задают фоновый цвет, цвет текста подписи и цвет круглой рамки вокруг команды для состояний :hover и :active:

 .win-appbar.customColor {
background-color: rgb(20, 20, 90);
}
.win-appbar.customColor .win-label {
color: rgb(90, 200, 90);
}
.win-appbar.customColor button:hover .win-commandring,
.win-appbar.customColor button:active .win-commandring {
background-color: rgba(90, 200, 90, 0.13);
border-color: rgb(90, 200, 90);
}

Все эти настройки стилей, кстати, применимы только к стандартному макету, основанному на командах. Если вы используете пользовательский макет, панель приложения просто содержит в себе все элементы, которые вы хотите на нее добавить, с любыми классами стилей, таким образом, вы можете управлять стилизацией как при работе с любыми другими HTML-элементами

Пользовательские значки

Ранее мы видели, что свойство icon элемента типа AppBarCommand обычно является одним из символов шрифта Segoe UI Symbol. Хотя для большинства нужд это подходит, время от времени может возникнуть необходимость в использовании символов из разных шрифтов (некоторые из нас просто не могут не пользоваться Wingdings!) или в отображении пользовательских изображений. Панель приложения поддерживает и то и другое.

Для использования различных шрифтов для всей панели приложения, просто добавьте класс к панели приложения и создайте правило, основанное на win-appbar :

win-appbar.customFont {
font-family: "Wingdings";
}
 

Для изменения шрифта определенной командной кнопки, добавьте класс к ее свойству extraClass (такому, как customButtonFont ) и создать правило со следующим селектором (как в Сценарии 1 модифицированного примера):

button.customButtonFont .win-commandimage {
font-family: "Wingdings";	
}
 

Для использования собственных изображений, выполните следующие шаги для масштаба разрешения 100%:

Для других масштабов разрешений, умножьте размеры на 1.4 (140%) и 1.8 (180%) и используйте в именах файлов суффиксы .scale-140 и .scale-180.

Для использования пользовательского значка, установите свойство icon командного элемента в значение базового URI изображения (без суффиксов .scale-1x0). Например, icon: 'url(images/icon.png)' .

Сценарий 3 примера, посвященного элементу управления HTML AppBar показывает использование пользовательских значков для кнопки Accept:

Значок хранится в файле, который называется accept.png, который выглядит примерно так, как показано ниже. Я настроил яркость и контраст, добавил рамку, чтобы вы могли четко увидеть каждую ячейку:

Объявление кнопок панели приложения, таким образом, выглядит так, как показано ниже (некоторые свойства опущены для краткости):

<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'cmdAccept', label:'Accept', icon:'url(images/accept.png)' }">
 

Обратите внимание на то, что хотя в примере нет различных значков для разных масштабов разрешения, он содержит варианты для тем с высокой контрастностью, это важное условие обеспечения соглашений по специальным возможностям, о которых мы поговорим в лекции 6 курса "Программная логика приложений для Windows 8, созданных с использованием HTML, CSS и JavaScript и их взаимодействие с системой". По этой причине элемент button включает style="-ms-high-contrast-adjust:none" для того, чтобы переопределить автоматическую настройку для тем с высокой контрастностью.

Командные меню

Следующий аспект панели приложения, который нуждается в пояснениях, касается тех команд, свойство type который установлено в значение flyout. В данном случае свойство flyout командного элемента должно идентифицировать объект WinJS.UI.Flyout или на элемент управления WinJS.UI.Menu (он является всплывающим элементом). Как мы упоминали ранее, всплывающие элементы или всплывающие меню наподобие этих используются тогда, когда в панели приложения нужно расположить слишком много связанных команд, или когда вам нужны другие типы элементов управления, которые не вполне подходят для их непосредственного расположения в панели приложения. Если вы пытаетесь воспользоваться кнопками с подписями "Еще", "Дополнительно", "Другие возможности", так как вы не можете решить, как организовать команды, это верный признак того, что приложение получается слишком сложным. Изыщите способы упрощения целей приложения, в итоге панель приложения не превратится в хранилище случайных элементов управления.

Мы подробнее поговорим о всплывающих элементах ниже в этой лекции, а сейчас посмотрим, как использовать их в панели приложения, как показано в Сценарии 6 примера "Всплывающие элементы управления HTML" (http://code.msdn.microsoft.com/windowsapps/Flyout-sample-258757b3) (обратите внимание, это не пример про панель приложения!):

В файле html/appbar-flyout.html этого примера мы видим, что кнопка панели приложения задана следующим образом:

<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'respondButton', label:'Respond', icon:'edit', type:'flyout', flyout:'respondFlyout'}"
>
 

Элемент respondFlyout, который здесь идентифицируется, определен ранее, в html/appbar-flyout.html. Обратите внимание на то, что подобный элемент должен быть объявлен раньше, чем панель приложения для того, чтобы его экземпляр был создан до создания панели приложения:

<div id="respondFlyout" data-win-control="WinJS.UI.Menu"
<button data-win-control="WinJS.UI.MenuCommand" 
data-win-options="{id:'alwaysSaveMenuItem',
label:'Always save drafts', type:'toggle', selected:'true'}">
</button>
<hr data-win-control="WinJS.UI.MenuCommand"
data-win-options="{id:'separator', type:'separator'}" />
<button data-win-control="WinJS.UI.MenuCommand"
data-win-options="{id:'replyMenuItem', label:'Reply'}">
</button>
<button data-win-control="WinJS.UI.MenuCommand"
data-win-options="{id:'replyAllMenuItem', label:'Reply All'}">
</button>	
<button data-win-control="WinJS.UI.MenuCommand"	
data-win-options="{id:'forwardMenuItem', label:'Forward'}">
</button>	
</div>
 

Вас не должно уже удивить то, что меню – это лишь еще один элемент управления WinJS, WinJS.UI.Menu, дочерние элементы которого определяютс содержимое меню. Все эти элементы, опять же, лишь элементы в DOM. Их события click подключаются к обработчикам в js/appbar-flyout.js с уже известным вам addEventListener. (В примере использована команда document.getElementById для получения элементов при вызове addEventListener. Эффективнее будет использовать метод панели приложения getCommandById, как в модифицированном примере работы с панелью приложения).

Каждый элемент меню, как вы можете видеть, это объект WinJS.UI.MenuCommand, мы так же рассмотрим подробности позднее, а сейчас вы можете видеть, что эти элементы имеют свойства id, label, type – это очень похоже на объекты WinJS.UI.AppBarCommand.

Вот и почти все, что нужно сделать, добавлю лишь, что когда элемент меню выбирают, нужно скрыть меню и, возможно, так же панель приложения (если она не находится в режиме залипания). Это показано в примере, в файле hs/appbar-flyout.js, в функции, которая называется hideFlyoutAndAppBar:

function hideFlyoutAndAppBar() {	
document.getElementById("respondFlyout").winControl.hide();
document.getElementById("appBar").winControl.hide();
 

Пользовательские панели приложений и панели навигации

Все это время мы изучали стандартный макет команд панели приложения, что, конечно, является самым простым способом использования этого элемента управления. Однако, стандартных возможностей хватает не всегда. Возможно, вы захотите расположить на панели приложения больше интересных элементов управления, в особенности это касается пользовательских элементов управления (таких, как средство для выбора цвета). Для подобных целей вы можете установить свойство панели приложения layout в значение ‘custom’ и задать любой HTML-макет для панели приложения, стилизовать его с помощью CSS и подключить обработчики любых необходимых событий в JavaScript.

Пользовательские макеты обычно используют для создании верхней панели навигации – то есть, панели приложения со свойством placement установленным в значение ‘top’ – так как командные кнопки – это обычно не тот пользовательский интерфейс, который вам нужен. Мы видели пример подобной панели приложения ранее, в приложении Weather, и навигационная панель в Internet Explorer устроена по тому же принципу:

Наш старый друг – пример элемента управления HTML AppBar (http://code.msdn.microsoft.com/windowsapps/App-bar-sample-a57eeae9) предоставляет пример пользовательского макета в Сценарии 5. В html/custom-layout.html мы видим разметку для пользовательской верхней панели приложения, содержащей произвольные элементы:

 <div id="customLayoutAppBar" data-win-control="WinJS.UI.AppBar" aria-label="Navigation Bar" 
data-win-options="{layout:'custom', placement:'top'}">
<header aria-label="Navigation bar" role="banner">
<button id="cmdBack" class="win-backbutton" aria-label="Back"
</button>
<div class="titleArea">
<h1 class="win-type-xx-large" tabindex="0"> 
Page Title </h1>
</div>
</header>
</div>

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

Как я упоминал в подразделе "Некоторые советы и секреты" (в разделе "Стилизация элементов управления), в лекции 4 курса "Введение в разработку приложений для Windows 8 с использованием HTML, CSS и JavaScript", вы можете подавить вывод прямоугольника фокуса с помощью правила <selector>:focus { outline: none; } в CSS. Для того, чтобы убрать его с кнопки "Назад", например, вы можете добавить следующее правило стиля в css/custom-layout.css

.win-appbar header .win-backbutton {
margin-left: 39px;	
margin-top: 59px;	
outline: none;	
	}
 

Снова обратите внимание на то, как это правило и другие правила в css/custom-layout.ss используют класс win-appbar как базовый селектор, но только потому, что он используется для стилизации других обычных классов, таких, как header или win-backbutton. Если вы используете особые классы в панели приложения или в навигационной панели, вы можете совсем не пользоваться селектором win-appbar.

Для того, чтобы реализовать навигационную панель, напоминающую таковую в Internet Explorer или в приложении Weather, вы можете использовать элемент управления ListView вместе с шаблонами элементов или пользовательскими функциями вывода элементов, где вы подключаете события itemInvoked к WinJS.Navigation.navigate и так далее. Опять же, здесь нет ничего особенно сложного: панель приложения с пользовательским макетом – это лишь всплывающий контейнер для других HTML-элементов.

Всплывающие элементы и меню

Возвращаясь к дискуссии о том, где размещать командные элементы управления, напомним, что всплывающий элемент управления WinJS.UI.Flyout – используется для целей подтверждения действий, сбора информации и получения ответов на вопросы при реакции на действия пользователя. Меню – элемент управления WinJS.UI.Menu – это, в свою очередь, особый вид всплывающего элемента, который содержит элементы управления WinJS.UI.MenuCommand вместо произвольного HTML-кода. На самом деле, WinJS.UI.Menu является, благодаря использованию WinJS.Class.define, прямым наследником WinJS.UI.Flyout , поэтому у них много общего. Что касается всплывающих элементов, они так же имеют общие черты с панелью приложения. (Классы панели приложения и всплывающего элемента являются наследниками базового класса WinJS.UI._Overlay , который является внутренним классом WinJS).

Совет. В дополнение к объекту ).

Прежде чем мы рассмотрим подробности, взглянем на некоторые изображения из примера "Всплывающий элемент управления HTML" (http://code.msdn.microsoft.com/windowsapps/Flyout-sample-258757b3), где мы уже видели меню, которое всплывает по команде элемента управления панели приложения. Элементы управления WinJS.UI.Flyout, использованные в сценариях 1-4 показаны на рис. 1.1. Обратите внимание на использование разного содержимого во всплывающих элементах и на то, что всплывающий элемент всегда расположен около элемента управления, который вызвал его, например, у кнопок Buy, Login, Format output text и около текста гиперссылки Lorem ipsum. Эти примеры показывают, что всплывающий элемент может содержать простое сообщение с кнопкой (Сцераний 1, для предупреждений и подтверждений), может содержать поля для ввода информации или изменения параметров (Сценарии 2 и 3), и может иметь заголовок (Сценарий 4). Сценарий 5, в свою очередь, содержит пример всплывающего меню заголовка WinJS.UI.Menu, которое мы увидим немного позже.

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

Вторая характеристика, так же актуальная для панели приложения, это закрытие неактивных всплывающих окон (light dismiss): щелчок мышью или прикосновение к области вне элемента управления скрывает его, как при нажатии клавиши Escape, что означает, что такое закрытие аналогично нажатию на кнопку Cancel (Отмена) или на кнопку закрытия в традиционном диалоговом окне. Преимущество такого подхода заключается в том, что нам не нужны видимые кнопки для этой цели, что помогает упрощению пользовательского интерфейса. В то же время, обратите внимание на то, что в Сценарии 3 рис. 1.1 нет кнопки OK или другого элемента управления, подтверждающего изменения, которые вы могли внести во всплывающем элементе. При рассматриваемой модели взаимодействия, изменения немедленно вступают в силу, таким образом ,закрытие всплывающего элемента не возвращает их к исходному состоянию и не отменяет. Если вас такое поведение не устраивает, вы можете разместить что-то вроде кнопки "Применить изменения" во всплывающем элементе и не вносить изменения до тех пор, пока кнопка не будет нажата. В таком случае, закрытие всплывающего элемента отменит изменения. (рис 1.1) Примеры всплывающих элементов управления из примера, который посвящен всплывающим элементам HTML

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

Примечание. В дополнение к приложениям, которые могут отображать собственные элементы WinJS.UI.Flyout, некоторые системные API (например, при создании дополнительных плиток) создают системные всплывающие элементы. В подобных случаях приложение получает событие blur, что ведет к закрытию панелей приложения. Для предотвращения подобного поведения, переведите панель приложения в режим залипания (sticky) при вызове этих API.

Свойства, методы и события WinJS.UI.Flyout

Большинство свойств, методов и событий элемента управления WinJS.UI.Flyout – это те, что мы уже рассматривали для панели приложения. Методы show и hide управляют его видимостью, свойство hidden показывает состояние видимости, в соответствующие моменты вызываются события beforeshow, aftershow, beforehide , и afterhide . Событие afterhide обычно используют для определения момента закрытия элемента.

Как и панель приложения, всплывающий элемент имеет свойство placement, но оно имеет другие значения, которые имеют смысл лишь в контексте свойств всплывающего элемента alignment и anchor . На самом деле, все три свойства – это необязательные параметры для метода show, так как они определяют позицию, в которой всплывающий элемент отобразится на экране. Значения placement и alignment могут быть установлены на сам элемент управления, так как они не обязательны при вызове show . (Заметим, что если вы не установите anchor в методе show , это свойство уже должно быть установлено на элемент управления, иначе show выдаст исключение.)

Свойство anchor идентифицирует элемент управления, который активирует всплывающий элемент, или любую другую операцию, которая может открыть всплывающий элемент (как в случае с подтверждением некоторого действия). Свойство placement, указывает, как всплывающий элемент должен располагаться по отношению к положению, заданному свойством anchor: 'top', 'bottom', 'left', 'right' , или 'auto' (по умолчанию). Обычно placement задают только тогда, когда всплывающий элемент может перекрыть важное содержимое. В противном случае вы рискуете тем, что всплывающий элемент будет уменьшен для того, чтобы занять доступное ему место. Содержимое всплывающего элемента при этом останется того же размера, что означает, - вот незадача! – что появятся полосы прокрутки! Таким образом, если только у вас нет достойной причины и справки от врача, используйте тип размещения 'auto' , так всплывающий элемент будет размещен там, где он может быть показан в полном размере. В том же духе, помните, что в прикрепленном режиме просмотра у вас есть лишь 320 пикселей по горизонтали, что означает, что всплывающий элемент, который вы показываете в данном режиме просмотра следует делать такого или меньшего размера.

Свойство alignment, в свою очередь, когда используется со свойством placement , установленным в 'top' или 'bottom' , определяет, как всплывающий элемент выравнивается с anchor: 'left', 'right' , или 'center' (по умолчанию). Само содержимое всплывающего элемента выравнивается посредством CSS как и любые HTML-элементы.

Если вам нужно стилизовать сам всплывающий элемент управления, вы можете задать стили в классе win-flyout , наподобшие шрифтов, выравнивания по умолчанию, полей и так далее. Что касается других классов стилей WinJS, родственных этому, используйте win-flyout как базу для более конкретных селекторов, если только вы не хотите стилизовать каждый всплывающий элемент в приложении. Обычно, на самом деле, вы так же исключаете win-menu из правила, таким образом, на всплывающие элементы меню такая стилизация не действует. Например, большинство сценариев в примере, который посвящен всплывающим элементам управления HTML, которые мы рассмотрим в дальнейшем, имеют правила наподобие такого:

 
.win-flyout:not(.win-menu) button,
.win-flyout:not(.win-menu) input[type="button"] {
margin-top: 16px;	
margin-left: 20px;	
float: right;

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

document.body.addEventListener("DOMNodeInserted", insertionHandler, false); 

Примеры всплывающих элементов

Всплывающий элемент управления создается так же, как любой другой элемент управления WinJS, с помощью атрибутов data-win-control и data-win-options, и обрабатывается WinJS.UI.process/processAll. Всплывающие элементы с относительно постоянным содержимым элементов обычно объявляют в разметке, где вы можете использовать привязку данных для некоторых свойств элементов во всплывающем элементе. Всплывающие элементы с динамическим содержимым, с другой стороны, могут быть созданы прямо из кода с использованием команды вида new WinJS.UI.Flyout(<element>, <options>) , и вы можете, безусловно, менять его дочерние элементы в любое время. Все это – лишь часть DOM! (Не повторяю ли я собственные слова?)

Как я говорил раньше (видимо, я повторяюсь) элемент управления WinJS.UI.Flyout может содержать произвольный HTML, стилизованный, как всегда, с помощью CSS. Всплывающий элемент для Сценария 1 в примере выглядит следующим образом в html/confirm-action.html (слегка сокращенный вид):

<div id="confirmFlyout" data-win-control="WinJS.UI.Flyout" aria-label="{Confirm purchase flyout}">
<div>Your account will be charged $252. </div>	
<button id="confirmButton">Complete Order</button>	
</div>
 

Всплывающий элемент для входа в систему из Сценария 2 похож, и он даже использует HTML-форму для прикрепления к кнопке Login события нажатия на кнопку Enter на клавиатуре:

<div id="loginFlyout" data-win-control="WinJS.UI.Flyout" aria-label="{Login flyout}" >
<form onsubmit="return false;" >
<p >
<label for="username" gt;Username <br / ></label >
<span id="usernameError" class="error" > </span >
<input type="text" id="username" / >
</p >
<p >
<label for="password">Password<br / ></label >
<span id="passwordError" class="error" ></span >
<input type="password" id="password" / >
</p >
<button id="submitLoginButton" >Login</button >
</form >
</div >
 

Всплывающий элемент отображается путем вызова его метода show . В Сценарии 1, например, событие кнопки click прикреплено к функции showConfirmFlyout (js/confirm-action.js), где кнопка Buy задается как элемент прикрепления. Обработка нажатия на кнопку Complete Order так же производится посредством обработчика события click, прикрепленного к этому элементу, и здесь мы вызовем метод hide для программного закрытия всплывающего элемента. Наконец, событие afterhide используется для выявления факта закрытия элемента:

var bought;

var page = WinJS.UI.Pages.define("/html/confirm-action.html", {
ready: function (element, options) {
document.getElementById("buyButton").addEventListener("click", showConfirmFlyout, false);
document.getElementById("confirmButton").addEventListener("click",
confirmOrder, false);
document.getElementById("confirmFlyout").addEventListener("afterhide",
onDismiss, false);
}

function showConfirmFlyout() {	
bought = false;	
var buyButton = document.getElementById("buyButton");	
document.getElementById("confirmFlyout").winControl.show(buyButton);
	

// Когда кнопка Buy нажата, скрыть всплывающий элемент, так как пользователь завершил работу с ним.
function confirmOrder() {	
bought = true;	
document.getElementById("confirmFlyout").winControl.hide();
}
// При закрытии элемента, определяет, был ли он закрыт потому, что пользователь нажал
// Кнопку Byu. Если нет, элемент был закрыт автоматически.	
function onDismiss() {	
if (!bought) {	
// (В примере сообщение о закрытии отображается на полотне)	
}	
 

Работа с элементами управления для входа в систему в Сценарии 2, в основном – это то же самое, с некоторыми дополнениями в виде кода, который позволяет проверить, были ли заполнены поля для ввода имени пользователя и пароля. Если это не так, обработчик нажатия кнопки Login показывает встроенное в элемент сообщение об ошибке и устанавливает фокус ввода на соответствующее поле:

Так как всплывающий элемент в Сценарии 2 немного больше, значение по умолчанию ‘auto’ для свойства placement (как в имитаторе) приводит к появлению элемента ниже кнопки, которая его вызывает. Выше этой кнопки не так много места. Поэтому попытаемся установить свойство placement в значение ‘top’ в вызове show:

function showLoginFlyout() {	
// ...	
document.getElementById("loginFlyout").winControl.show(loginButton, "top");
} 

После этого вы можете увидеть, как во всплывающем элементе появляются полосы прокрутки, так как его размер слишком мал:

Каким словом я раньше это называл? "Незадача"?

Двигаемся дальше, к Сценарию 3, в котором всплывающий элемент определен в разметке, где он содержит элементы управления label, select, input. В JavaSctipt, однако, он прослушивает события изменения этих элеменов и применяет полученные значения к элементам вывода данных на полотне приложения:

 var page = WinJS.UI.Pages.define("/html/change-settings.html", {	
ready: function (element, options) {	
// ...	
document.getElementById("textColor").addEventListener("change", changeColor, false);
document.getElementById("textSize").addEventListener("change", changeSize, false);	
}	
});

// Изменение цвета текста	
function changeColor() {	
document.getElementById("outputText").style.color =
document.getElementById("textColor").value;

// Изменение размера текста
function changeSize() {
document.getElementById("outputText").style.fontSize =
document.getElementById("textSize").value + "pt";

Если бы у этого всплывающего элемента была бы кнопка Применить (Apply) вместо его немедленной реакции на изменения, ее обработчик click получал бы текущее выделение и значение из ползунка и использовал бы их для того, чтобы выполнить действия, аналогичные тем, что производятся в функциях changeColor и changeSize.

И, наконец, в Сценарии 4 мы видим всплывающий элемент с заголовком, который является просто элементом в разметке, выводящим крупный текст. Сам по себе всплывающий элемент не имеет выделенного описания для заголовков:

<div id="moreInfoFlyout" data-win-control="WinJS.UI.Flyout" aria-label="{More info flyout}">
<div class="win-type-x-large">Lorem Ipsum</div>	
<div>	
Lorem Ipsum is text used as a placeholder by designers...	
</div>	
</div>
 

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

Меню и команды меню

Элемент управления WinJS.UI.Menu отличает от более общего элемента WinJS.UI.Flyout то, что меню ожидает, что все его дочерние элементы будут объектами типа WinJS.UI.MenuCommand , так же, как стандартный макет панели приложения ожидает объекты AppBarCommand (и его экземпляр не будет создан, если вы объявите у него какие-нибудь другие дочерние элементы). На самом деле, у меню есть общие характеристики и с панелью приложения, и со всплывающим элементом:

Меню поддерживает два стиля, влияющих на его отображение – win-menu и win-command – который можно использовать для создания более конкретных селекторов, как мы видели, для всего меню или для отдельных текстовых команд.

Объекты MenuCommand так же очень похожи на объекты AppBarCommand. У них много одинаковых свойств: id, label, type ('button', 'toggle', 'flyout' , и 'separator' ), disabled, extraClass, flyout, hidden, onclick , и selected . У команд меню нет значков, разделов и всплывающих подсказок, но из type вы можете видеть, что элементы меню могут быть кнопками (включая полностью текстовые элементы), элементами с возможностью установки флагов, разделителями и, кроме того, другими всплывающими элементами. В последнем случае, вторичное меню заменит первое вместо того, чтобы отображаться рядом с ним, а чтобы быть полностью честным, я должен все же видеть вторичное меню, используемое в реальном приложении. Тем не менее, такая возможность поддерживается.

Мы уже видели, как использовать всплывающие меню с помощью команд панели приложения, что показано в Сценарии 6 примера, посвященного всплывающему элементу управления HTML (посмотрите раздел "Командные меню" выше). Другая типичная сфера использования – реализация того, что выглядит как выпадающее меню заголовочного элемента, что показано в Сценарии 5. Здесь (html/header-menu.html), показан стандартный дизайн помещения символа перевернутой угловой скобки (#xe099) в конце заголовка:

<header aria-label="Header content" role="banner">
<button class="win-backbutton" aria-label="Back"></button>
<div class="titlearea win-type-ellipsis">

<button class="titlecontainer">	
<h1>	
<span class="pagetitle">Music</span>	
<span class="chevron win-type-x-large" >  #xe099 </span>
</h1>	

</button>	
</div>	
</header>
 

Обратите внимание на то, что весь заголовок помещен в элемент управления button (кнопка), ее обработчик click может отображать меню с помощью метода show:

document.querySelector(".titlearea").addEventListener("click", showHeaderMenu, false);

function showHeaderMenu() {
var title = document.querySelector("header .titlearea");
var menu = document.getElementById("headerMenu").winControl;
menu.anchor = title; menu.placement = "bottom"; 
menu.alignment = "left";
menu.show();
}
 

Всплывающий элемент (определенный как headerMenu в html/header-menu.html) появляется, когда вы щелкаете в любом месте заголовка (а не только на угловой скобке, которая является обычным символом в тексте заголовка):

Отдельные команды меню – это простые элементы button, поэтому вы можете присоединить к ним обработчики click если вам это нужно. Как и в случае с панелью приложения, лучше всего использовать метод элемента управления меню getCommandById для обнаружения этих элементов, так как это гораздо эффективнее, чем document.getElementById (что, к сожалению, используется в примере из SDK).

Для того чтобы увидеть в действии вторичное меню, попытайтесь добавить следующий элемент secondaryMenu в html/header-menu.thml перед элементом headerMenu и добавить элемент button в headerMenu, свойство flyout которого ссылается на secondaryMenu:

<div id="secondaryMenu" data-win-control="WinJS.UI.Menu">	
<button data-win-control="WinJS.UI.MenuCommand"	
data-win-options="{id:'command1', label:'Command 1'}"></button>
<button data-win-control="WinJS.UI.MenuCommand"	
data-win-options="{id:'command2', label:'Command 2'}"></button>
<button data-win-control="WinJS.UI.MenuCommand"	
data-win-options="{id:'command3', label:'Command 3'}"></button>
</div>	
<div id="headerMenu" data-win-control="WinJS.UI.Menu">	
<!-- ... -->	
<button data-win-control="WinJS.UI.MenuCommand"	
data-win-options="{id:'showFlyout', label:'Show secondary menu',
type:'flyout', flyout:'secondaryMenu'}">	
</button>	
</div>
 

Кроме того, перейдите в css/header-menu.css и установите стиль width элемента #headerMeny в значение 200px. С этими изменениями первое меню будет выглядеть так, как показано ниже, изменение цвета заголовка – результат действия эффекта зависания над ним указателя мыши:

Когда вы выберете пункт Show secondary meny (Показать вторичное меню), первое меню будет закрыто и откроется меню второго уровня:

Другой пример использования всплывающих элементов в заголовке можно найти в примере "Адаптивный макет с использованием CSS" (http://code.msdn.microsoft.com/windowsapps/Adaptive-layout-with-sample-062e7fe2), который мы видели в лекции 6 курса "Введение в разработку приложений для Windows 8 с использованием HTML, CSS и JavaScript". Он реализован так же, как показано выше, с добавлением механизмов, которые изменяют содержимое страницы в ответ на выделение.

Контекстные меню

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

Совет. Если вы обрабатываете событие нажатий правой кнопки мыши на элемент, убедитесь в том, что для этого элемента отключено стандартное поведение, которое подразумевает отображение панели приложения. Таким образом, используйте событие щелчка правой кнопки мыши разумно, так как пользователи привыкли пользоваться правой кнопкой для вызова панели приложения. Обратите так же внимание на то, что вы можете программно открыть панель приложения, используя ее метод show.

Пример "Контекстное меню" (http://code.msdn.microsoft.com/windowsapps/Context-menu-sample-40840351) предоставляет нам некоторый контекст – я знаю, что это неудачная игра слов! В любом случае, вам нужно лишь прослушивать событие HTML contextmenu для соответствующего элемента. Вам не нужно заботиться особым образом об обработке касаний или о событиях клавиатуры. Сценарий 1 примера, например, имеет невыделяемый элемент attachment, для которого прослушивается вышеупомянутое событие (html/scenario1.html):

document.getElementById("attachment").addEventListener("contextmenu", attachmentHandler, false); 

В обработчике события, вы создаете объект ) (это объект из WinRT, не из WinJS!), заполняет его объектами (они содержат подпись элемента и обработчик события) или объектами ), и затем вызывает метод меню showAsync (js/scenario1.js):

function attachmentHandler(e) {
var menu = new Windows.UI.Popups.PopupMenu();
menu.commands.append(new Windows.UI.Popups.UICommand("Open with", onOpenWith));
menu.commands.append(new Windows.UI.Popups.UICommand("Save attachment",
onSaveAttachment));	

menu.showAsync({ x: e.clientX, y: e.clientY }).done(function (invokedCommand) {
if (invokedCommand === null) {	
// Команда - это null если ни одна команда не была активирована.	
}	
});
 

Обратите внимание на то, что результат метода Пример, на самом деле, вызывает здесь не done, а then. Если вам интересно, почему существует подобная последовательность, это потому, что метод done был представлен не в начале разработки Windows 8, а тогда, когда стало ясно, что нам нужен более совершенный механизм для обработки ошибок в promise-вызовах, объединенных в цепочку. В результате, множество SDK-примеров и кода в документации все еще используют then вместо done, когда обрабатывают последний promise-вызов в цепочке. Такой подход все еще работает, это лишь приводит к тому, что сведения об ошибках, возникающих в цепочке, теряются, что скрывает возможные ошибки ), который показывает, где следует появиться меню по отношению к указателю мыши или точке касания. Меню размещается выше данной точки и выровнено по центру.

Объект PopupMenu так же поддерживает метод, который называется showForSelectionAsync, первым аргументом которого является объект ), который описывает область выделения. Опять же, меню размещается выше прямоугольника выделения с выравниванием по центру. Это показано в Сценарии 2 примера в js/scenario2.js:

//В обработчике contextmenu 
menu.showForSelectionAsync(getSelectionRect()).then(function (invokedCommand) {
// ...	

function getSelectionRect() {
var selectionRect = document.selection.createRange().getBoundingClientRect();

var rect = {
x: getClientCoordinates(selectionRect.left), 
y: getClientCoordinates(selectionRect.top),
width: getClientCoordinates(selectionRect.width),
height: getClientCoordinates(selectionRect.height)
};
return rect;
};
 

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

Последнее замечание, касающееся контекстных меню: так как они создаются с помощью API WinRT, а не с помощью элементов управления WinJS, меню не существуют в DOM, они не известны DOM, что объясняет использование других конструкций WinRT – как point (Точка) и Rect (Прямоугольник). Подобное утверждение так же справедливо для окон сообщений, которые станут последней темой этой лекции.

Диалоговые окна сообщений

Последняя тема этой лекции, касающаяся командного интерфейса, посвящена диалоговым окнам сообщений. Как и контекстные меню, эти всплывающие элементы относятся к WinRT а не к WinJS, для работы с ними используется API Windows.UI.MessageDialog (http://msdn.microsoft.com/library/windows/apps/windows.ui.popups.messagedialog.aspx). Это, опять же, означает, что окна сообщений просто появляются поверх текущей страницы и не присутствуют в DOM. Диалоговые окна автоматически затеняют текущую страницу приложения и блокируют события ввода от приложения до тех пор, пока пользователь не отреагирует на окно сообщения.

В материале "Руководство и контрольный список для окон сообщений" (http://msdn.microsoft.com/library/windows/apps/hh738363.aspx) показаны варианты их использования:

Интерфейс диалоговых окон очень прост. Вы создаете объект диалогового окна сообщения командой new Windows.UI.Popups.MessageDialog. Конструктор принимает в качесве обязательного параметра строку с содержимым сообщения и с необязательным вторым строковым параметром, содержащим заголовок окна. Окно сообщения имеет свойства content и title, которые вы можете использовать независимо друг от друга. В любом случае, строковые параметры поддерживают лишь обычный текст.

После этого вы конфигурируете диалоговое окно с помощью его свойств commands, options, defaultCommandIndex (команда, связанная с клавишей Enter) и cancelCommandIndex (команда, связанная с клавишей Escape).

Значения параметра options берутся из перечисления Windows.UI.Popups.MessageDialogOptions, которое содержит лишь два члена: none (значение по умолчанию, для случаев, когда особое поведение не требуется), и acceptUserInputAfterDelay (что приводит к тому, что окно сообщения некоторое время не воспринимает пользовательский ввод для того, чтобы предотвратить кликджекинг (clickjaking); это существенно, преимущественно, для интернет-браузеров, которые загружают произвольное веб-содержимое и практически не требуется большинству приложений).

Свойство command содержит до трех объектов типа тех же самых, которые используются в контекстных меню. Каждая из команд содержит свойства id, label и invoked, к которому вы подключаете обработчик для команды. Обратите внимание на то, работа свойств defaultCommandIndex и cancelCommandIndex основана на индексах массива commands, а не на id этих команд. Кроме того, если вы не добавите собственные команды, диалоговое окно сообщения отобразится с единственной командой по умолчанию – Закрыть (Close).

И, наконец, когда диалоговое окно настроено, вы отображаете его, вызывая его метод showAsync. Как и в случае с контекстным меню, в результате выбранный пользователем объект UICommand, который передается обработчику завершения, который вы предоставили для метода done promise-объекта. Обычно вам не нужно получать этот результат, так как выбранная команда имеет связанный с ней обработчик invoked, где вы и выполняете действия, соответствующие команде.

Примечание. Если в то время, когда активно окно сообщения, активируются чудо-кнопки Поиск, Общий доступ, Устройства или Параметры, или если приложение активируется для обслуживания контракта, диалоговое окно сообщения будет закрыто и без выбора какой-либо команды в нем. Будет осуществлен вызов обработчика завершения для showAsync, с результатом, установленным на команду по умолчанию. Знайте об этом, если вы используете обработчик завершения для обработки подобных команд.

Пример "Диалоговое окно сообщения" (http://code.msdn.microsoft.com/windowsapps/Message-dialog-sample-00c928f5) – это один из самых простых примеров во всем SDK! Он показывает разные варианты использования API окон сообщений. Сценарий 1 показывает окно сообщения с заголовком и двумя командными кнопками, вторая командная кнопка (с индексом 1) установлена как кнопка по умолчанию. Вот как это выглядит:

Сценарий 2 показывает вывод команды по умолчанию – Закрыть (Close) с сообщением и без заголовка:

Сценарий 3 похож на Сценарий 1, но использует обработчик завершения метода showAsync().done для обработки команды, выбранной пользователем. Вы можете использовать этот пример для того, чтобы увидеть эффект активации чудо-кнопок при открытом диалоговом окне.

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

И это действительно все, что относится к окнам сообщений!

Улучшение обработки ошибок в "Here My Am!"

Для того, чтобы завершить эту лекцию и свести воедино большую часть того, о чем мы говорили, внесем некоторые изменения в "Here My Am!". В последний раз мы работали над этой программой, улучшая обработку различных ошибок. В ее теперешнем состоянии программа ведет себя не очень хорошо. А именно, есть сложности в следующих областях:

Приложение "Here My Am!" (7) для этой лекции учитывает эти вопросы. Во-первых, я добавил изображение, которое должно выводиться при ошибке, в html/map.html (изображение находится по адресу html/maperror.png), таким образом, если не удается загрузить скрипт карт Bing, вместо карты будет выведено изображение (в этом случае стиль отображения none будет удален):

<img id="errorImage" style="display: none; width: 100%; height: 100%;" src="maperror.png" /> 

Кроме того, я добавил к изображению обработчик события click, который перезагружает содержимое iframe с document.location.reload(true). Когда это сделано, я могу убрать исключения, которые возникли ранее, когда карта не могла быть создана, предотвращая аварийное завершение приложения. Вот как выглядит ситуация, когда карта не может быть создана:

Для того, чтобы протестировать такой вариант развития событий, вам нужно отключиться от Интернет, деинсталлировать приложение (для очистки кэшированных скриптов карты; в противном случае карта, все равно, будет загружаться!) и снова запустить приложение. Ошибка должна произойти в начале метода init в файле html/map.html, что приведет к появлению изображения путем удаления стиля по умолчанию display: none и подключения обработчика click . Затем снова подключитесь к Интернету и нажмите на изображение. Карта должна перезагрузиться, но если проблема с соединением сохранилась, снова появится изображение, сигнализирующее об ошибке.

Вторая проблема – добавление возможности обновлять наше местоположение – просто решаема с помощью панели приложения. Я добавил такой элемент управления на страницу default.html с одной командой:

<div id="appbar" data-win-control="WinJS.UI.AppBar" data-win-options="">
<button data-win-control="WinJS.UI.AppBarCommand"	
data-win-options="{id:'cmdRefreshLocation', label:'Refresh location',
icon:'globe', section:'global', tooltip:'Refresh your location'}">
</button>	
</div>
 

Эта команда подключена внутри pages/home/home.js в методе ready элемента управления страницы:

var appbar = document.getElementById("appbar").winControl;
appbar.getCommandById("cmdRefreshLocation").addEventListener("click", this.tryRefresh.bind(this));
 

Здесь обработчик tryRefresh, так же в элементе управления страницы, скрывает панель приложения и вызывает другой новый метод, refreshPosition, куда я поместил код, который получает сведения о местоположении и обновляет карту:

tryRefresh: function () {	
//Скрыть панель приложения и попробовать снова	
var appbar = document.getElementById("appbar").winControl.hide();
this.refreshPosition();	
},
 

Мне так же понадобилось настроить функцию pinLocation в html/map.html. Без команды обновления местоположения, эта функция вызывалась лишь однажды, при запуске приложения. Так как теперь она может быть вызвана много раз, нам нужно удалить любые существующие метки на карте, прежде чем добавлять метку для нового местоположения. Это делается путем вызова map.entities.pop перед уже существующим вызовом map.entities.push, который отмечает новое местоположение.

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

Что касается третьей проблемы – дать пользователю знать о том, что приложение пытается получить данные о местоположении – мы можем показать маленькое всплывающее сообщение сразу же после попытки вызова getGeopositionAsync из WinRT. Всплывающий элемент, определенный в pages/home/home.html (в нашем элементе управления страницы) центрирован вдоль нижней части области карты:

<div id="retryFlyout" data-win-control="WinJS.UI.Flyout" aria-label="{Trying geolocation}"
data-win-options="{anchor: 'map', placement: 'bottom', alignment: 'center'}">	
<div class="win-type-large">Attempting to obtain geolocation...</div>	
</div>
 

Функция refreshFunction которую мы только что добавили в pages/home/home.js является отличным местом для отображения всплывающего окна сразу перед вызовом getGeopositionAsync:

 refreshPosition: function () {
document.getElementById("retryFlyout").winControl.show(); 
var gl = new Windows.Devices.Geolocation.Geolocator();

gl.getGeopositionAsync().done(function (position) {
//...

//Всегда скрывать всплывающий элемент document.getElementById("retryFlyout").winControl.hide();

//...
}, function (error) {
//...

//Всегда скрывать всплывающий элемент	
document.getElementById("retryFlyout").winControl.hide();
});	
},

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

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

Для встроенного сообщения, я добавил плавающий элемент div, который позиционирован примерно на трети расстояния от верхнего края карты. Он определен в defined/home/home.html, как показано, в качестве элемента одного уровня с iframe:

<div id="locationSection" class="subsection" aria-label="Location section">	
<h2 class="group-title" role="heading">Location</h2>	
<iframe id="map" class="graphic" src="ms-appx-web:///html/map.html"	
aria-label="Map"></iframe>	
<div id="floatingError" class="win-type-x-large">Unable to obtain geolocation;<br />
use the app bar to try again.</div>	
</div>
 

Стиль для правила #floatingError в pages/home/home.css задает внешний вид и расположение элемента:

#floatingError { 
display: none; float: left;
-ms-grid-column: 1;
-ms-grid-row: 2;
-ms-grid-row-align: start;
width: 100%;
text-align: center;
background-color: rgba(128, 0, 0, 0.5);
margin-top: 20%;
}
 

Так как этот элемент размещен в той же ячейке сетки, что и карта со стилем float, это выглядит как хорошо выглядящее наложение:

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

С параметром display: none в CSS, сообщение об ошибке первоначально скрыто, как это и должно быть. Если мы попадаем в обработчик ошибки для getGeolocationAsync , мы устанавливаем style.display в значение block , что отображает элемент:

document.getElementById("floatingError").style.display = "block"; 

Мы снова скрываем сообщение внутри функции tryRefresh, которая вызывается посредством команды на панели приложения, таким образом, сообщение остается скрытым, если ошибка повторяется:

tryRefresh: function () {	
document.getElementById("floatingError").style.display = "none";
//...	
},
 

Так же мы можем добавить окно сообщения, если мы обнаружим, что сетевое соединение потеряно, и, таким образом, не можем обновить местоположение. Как мы увидим в лекции 3 курса "Программная логика приложений для Windows 8, созданных с использованием HTML, CSS и JavaScript и их взаимодействие с системой", это можно сделать с помощью события ). В подобном случае вполне можно воспользоваться окном сообщения, так как происходящее не связано с непосредственными действиями пользователя.

Кроме того, стоит отметить, что если бы мы использовали элемент управления из Bing Maps SDK в данном приложении, скрипт, который мы загружаем из удаленного источника, хранился бы в пакете нашего приложения, таким образом, устраняя причину первой ошибки. Мы внесем это изменение в следующую версию программы

Что мы только что изучили