Программирование мобильных устройств на платформе .NET Compact Framework
Шрифт:
Стратегии проектирования высокопроизводительных пользовательских интерфейсов
Сложность написания кода пользовательского интерфейса объясняется тем, что он представляет собой пограничную область, в которой ваш код взаимодействует как с операционной системой, так и с конечным пользователем. Пользовательский интерфейс находится в буквальном смысле слова между ними и играет роль посредника при обмене запросами, связывающими между собой пользователя и операционную систему. Как проектировщик приложения, вы должны ответить на тысячи вопросов:
■ Какие стандартные или пользовательские элементы управления следует применять для отображения данных и организации взаимодействия с пользователем?
■ Имеет ли смысл создать собственные нестандартные элементы управления, или же лучше расширить свойства уже существующих элементов управления с тем, чтобы они соответствовали вашим конкретным нуждам?
■ Какие стратегии
■ На какие управляющие события необходимо реагировать? В каких случаях реакция на эти события должна подавляться?
■ Можно ли уменьшить количество событий, запускаемых при выполнении обычных или часто повторяющихся задач?
■ Существует ли необходимость в форсировании немедленного обновления или перерисовки элементов управления ради поддержания в пользователе уверенности в том, что его команды воспринимаются и исполняются, если при этом страдает общая производительность приложения?
С учетом того, что перечень этих вопросов довольно большой, число возможных вариантов реализации кода, обеспечивающего удовлетворение тех или потребностей пользовательского интерфейса, оказывается практически неограниченным. Наряду с предоставлением вам широкой свободы действий, эта ситуация порождает риск принятия случайных или неэффективных решений. Представьте, что вы пришли в мебельный магазин покупать диван, а вам выдали несколько упаковок с деталями, количество которых явно превышает необходимое, и предложили самому заняться сборкой дивана, не удосужившись снабдить вас никакими дополнительными инструкциями. Возможно, собранная вами конструкция окажется прочной, и будет выглядеть вполне прилично, но не исключено, что результат вашего труда окажется менее привлекательным в отношении дизайна и будет походить скорее на настил, сооруженный первобытным человеком, чем на современный диван. Не имея инструкций, стратегии и хорошего технического руководства, вы закончите, вероятнее всего, вторым вариантом. При наличии же понятной схемы сборки исход окажется благополучным. Как и в случае с нашим вымышленным диваном, после того как вы соберете воедино все части приложения, вам будет очень трудно вновь отделить их одну от другой для внесения возможных изменений, связанных с пересмотром проекта. Если вы не хотите, чтобы конечный результат оказался посредственным, и не желаете начинать все заново с самого начала, вы должны продумать стратегии своих действий, которыми вы будете руководствоваться и которые будут гарантировать, что процесс разработки пользовательского интерфейса приложения все время развивается в правильном русле
Ниже приведены некоторые из основных стратегий проектирования, ориентированных на создание высокопроизводительных пользовательских интерфейсов.
Использование встроенных средств повышения производительности
Если среда выполнения мобильного приложения, которую вы используете, предлагает для создания высокопроизводительных кодов пользовательских интерфейсов специальные возможности, вы обязательно должны ими воспользоваться. Более того, вы должны очень внимательно изучить перечень событий, свойств и методов, относящихся к используемым вами элементам управления, и попытаться найти среди них те, которые особенно подходят для повышения производительности интерфейса. Лучшим способом узнать как можно больше об этих возможностях каркаса пользовательского интерфейса является исследование членов его классов окон, форм и элементов управления. Кроме того, полезно внимательно изучить перегруженные версии методов, предназначенных для решения наиболее часто возникающих задач программирования, и выяснить, не найдутся ли методы, позволяющие выполнять операции в пакетном режиме вместо того, чтобы повторно вызывать один и тот же метод в цикле. Как несложно догадаться, выполнение операций в пакетном режиме обычно происходит гораздо быстрее. Для такого исследования вам, как правило, потребуется каких- нибудь несколько минут, но вы сами удивитесь, как много нового для себя вы сможетe обнаружить; очень часто плохое функционирование кода пользовательского интерфейса объясняется просто тем, что для достижения тех или иных целей используются далеко не самые эффективные свойства или методы, или тем, что вызываются методы, приостанавливающие операции с пользовательским интерфейсом на время выполнения его обновлений.
Элементы управления TreeView и ListView используются для отображения наборов взаимосвязанных данных в пользовательских интерфейсах. Поскольку эти элементы управления работают с наборами данных, часто возникает необходимость в добавлении к ним или удалении из них сразу целых групп элементов
• .BeginUpdate/EndUpdate. Оба эти метода присутствуют как в TreeView, так и в ListView, и предназначены для приостановки и возобновления автоматической перерисовки элемента управления на экране. Вызов метода BeginUpdate указывает на то, что элемент управления не должен автоматически перерисовываться всякий раз, когда в него добавляются или из него удаляются элементы данных, тогда как вызов метода EndUpdate восстанавливает режим автоматической перерисовки элемента управления. Выполнение необязательных операций перерисовки экрана может отрицательно сказываться на производительности приложения. Если в процессе работы вашего приложения возникает необходимость в помещении в элемент управления или исключении из него многочисленных данных, то соответствующий участок кода целесообразно окружить парой вызовов BeginUpdate и EndUpdate.
• .AddRange. Для коллекции узлов элемента управления TreeView предусмотрен метод AddRange (например, treeView1.Nodes.AddRange), обеспечивающий групповое добавление узлов в TreeView. Такой "пакетный" режим обработки является гораздо более предпочтительным по сравнению с простым итеративным добавлением каждого узла по отдельности.
Используя эти эффективные встроенные механизмы, вы можете добиться существенного выигрыша в отношении как производительности, так и бесперебойности работы пользовательского интерфейса. Если с каким-либо элементом управления приходится работать особенно часто, то стоит просмотреть список его свойств и методов, чтобы выяснить, не найдутся ли среди них такие, использование которых позволит увеличить производительность.
Приведенный в листинге 11.1 пример предназначен для количественной оценки эффективности трех различных методик работы с элементами управления TreeView среды .NET Compact Framework. Используя Visual Studio .NET, создайте новый проект C# для мобильного приложения, выбрав в качестве целевой платформы устройство Pocket PC. Убедившись в том, что вы находитесь в режиме конструктора, добавьте в пустую форму элемент управления TreeView и пять кнопок, как показано на рис. 11.1.
Все, что вы должны для этого сделать — это дважды щелкнуть на кнопке формы. Имя добавленной функции будет состоять из имени элемента управления (например, button1) и суффикса _Click. Visual Studio выполнит следующее: 1) создаст для вас функцию обработчика событий, 2) запишет код в функцию InitializeComponent формы, предназначенную для подключения только что созданного обработчика события щелчка, и 3) откроет окно редактора кода, чтобы вы могли ввести в нем код для обработчика события. При желании вы можете назвать кнопку по-другому, изменив свойство Name в окне Properties (окно справа на рис. 11.1). Целесообразно сделать это до двойного щелчка на кнопке с целью создания и подключения обработчика события, поскольку функция обработчика создается с использованием текущего имени элемента управления. Если имя элемента управления будет изменено уже после создания этой функции, обработчик по-прежнему останется связанным с ним должным образом, но его имя не будет согласовываться с новым именем элемента управления. Обеспечить совпадение имен в этом случае вам придется вручную; сделать это не составляет особого труда, но для этого вам придется выполнить лишнюю работу.
Представленный в листинге 11.1 код состоит из набора обработчиков событий для различных кнопок, которые имеются на вашей форме. Фактические имена используемых функций будут происходить от имен, присвоенных соответствующим кнопкам. В своем коде я использовал для кнопок следующие имена: UnOptimizedFill, UnOptimizedClear, UseBeginEndUpdateForFill, UseBeginEndUpdateForClear и FillArrayBeforeAttachingToTree. Если вы используете заданные по умолчанию имена, которые предложит вам Visual Studio .NET, то у вас будут кнопки с именами button1, button2, button3, button4 и button5 и функции обработчиков событий с другими именами, которые надо будет соответственно изменить.
Рис. 11.1. Конструктор форм среды Visual Studio .NET с размещенными на форме элементами управления TreeView и Button
В любом случае, проще всего сначала создать и связать с кнопками пустые обработчики событий, выполняя для этого двойные щелчки на каждой из кнопок в конструкторе форм Visual Studio .NET, а затем вставить приведенный в листинге код обработчиков в созданные для вас определения функций.