Программирование мобильных устройств на платформе .NET Compact Framework - Иво Салмре

■ Не будет ли эффективнее привлечь пользовательский элемент управления для отображения той информации, которая в настоящее время представляется несколькими элементами управления?  Такое решение должно быть тщательно взвешено. Создание специализированного элемента управления может оказаться неплохим способом повышения эффективности использования пространства пользовательского интерфейса, но при этом следует проанализировать, насколько такое решение будет удовлетворительным с учетом следующих факторов: 1) разработка пользовательского элемента управления требует намного больших усилий, чем использование уже существующих и протестированных элементов управления, и 2) создание новой метафоры пользовательского интерфейса может затруднить его использование. Конечные пользователи уже знают, как использовать существующие элементы управления, тогда как к любым вновь введенным вами концепциям им придется привыкать. Тем не менее, в некоторых случаях такая работа является оправданной и может давать впечатляющие результаты.

Не все участки экрана равнозначны. Элемент управления, размещенный вверху, внизу, слева, справа или посередине экрана будет обладать различными свойствами применимости. Эти свойства часто меняются при переходе от одного класса устройств к другому. Так, элементы управления Pocket PC, принимающие текстовый ввод, следует размещать в верхней части экрана, поскольку в этих устройствах предусмотрена всплывающая программная клавиатура (SIP), которая, если вам необходимо ввести текст, отображается в нижней части экрана. Расположением элементов управления, которые вы размещаете на экране, должны управлять следующие два фактора:

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

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

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

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

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

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

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

Разработка улучшенных пользовательских интерфейсов средствами .NET Compact Framework

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

Динамическое создание элементов управления

Возможность динамического создания элементов управления может оказаться полезной. Как показывают рис. 13.8 и листинг 13.2, в .NET Compact Framework сделать это не сложно. Динамические элементы управления удобно использовать в нескольких ситуациях:

■ Когда форма загружается очень медленно.  Если форма содержит множество элементов управления или она достаточно тяжеловесна, то для ее инициализации требуется проделать большой объем работы. При создании и загрузке формы инициализируются все элементы управления, размещенные на ней во время проектирования. Все, что для этого необходимо, выполняется в функции InitializeComponent(); содержимым этой функции управляет конструктор форм, и при желании вы можете исследовать упомянутую функцию. Если вы хотите ускорить загрузку формы, то можете отложить создание элемента управления до тех пор, пока в нем не возникнет необходимости. Примечание. Вы также можете воспользоваться кодом, автоматически сгенерированным для вас в функции InitializeComponent(), и попытаться вручную оптимизировать его. Поступая таким образом, вы должны поместить собственный код в функцию с отдельным именем, которое исключит вероятность того, что по случайности она будет перекрыта функцией среды разработки. Вы также должны понимать, что теперь при проектировании своей формы вы можете лишиться помощи конструктора форм. Как и в случае любой оптимизации, вы обязательно должны получать количественную оценку ее эффективности, чтобы быть уверенным в том, что добились с ее помощью те результаты, на которые рассчитывали.