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

■ Улучшенные условия: отображение курсора ожидания в течение того времени, пока приложение не в состоянии отвечать на запросы. Отображение курсора ожидания преследует две важные цели. Во-первых, он извещает конечных пользователей о том, что работа для них выполняется, а во-вторых, его исчезновение указывает на то, что работа завершена и приложением вновь можно пользоваться. Если учесть, что отображение курсора ожидания обычно не составляет никакого труда, то нежеланию приложить даже столь незначительные усилия к тому, чтобы улучшить интерактивные свойства приложения, не может быть никаких оправданий. Любая операция, для выполнения которой требуется более нескольких десятых долей секунды, тормозит пользовательский интерфейс до такой степени, что пользователь сможет это почувствовать, и поэтому нет ни малейших оснований для того, чтобы в этой ситуации не дать пользователю понять, что приложение выполняет нужную для него работу. Используя курсор ожидания, вы на несколько секунд "покупаете" понимание и терпение со стороны пользователя устройства, но если выполнение работы занимает более нескольких секунд, то вам следует прибегнуть к более информативному индикатору выполнения, нежели простой курсор ожидания. Кроме того, если почти любое действие пользователя сопровождается появлением курсора ожидания, вам следует позаботиться об оптимизации мобильного приложения и выполнении части обработки в фоновом режиме; задержки могут быть приемлемыми в некоторых ситуациях, но далеко не во всех. 

■ Лучшие условия; отображение индикатора выполнения или сопроводительного текста, поясняющего, что именно происходит в данный момент. Если операция, завершения которой вынужден дожидаться пользователь, длится более нескольких секунд, следует подумать об использовании индикатора выполнения или текстовых пояснений, которые информируют пользователя о том, что происходит в данный момент, отображают процентную долю оставшейся работы или оценку времени, оставшегося до завершения операции. Отображение курсора ожидания не препятствует отображению текста, информирующего пользователя о том, как продвигается работа. Пояснительный текст, который говорит пользователю о том, какая именно работа для него выполняется, можно отображать позади курсора ожидания. Полезной будет любая информация, указывающая на степень выполнения работы. Информативный текст полезен, в частности, тем, что помогает поддерживать в пользователе чувство причастности к вычислительному процессу. Так, алгоритм, загружающий информацию с сервера, может отображать такую последовательность обновляющихся сообщений: "Поиск сервера", "Сервер найден. Выполняется регистрация", "Загружается информация (10%)", "Загружается информация (60%)", "Готово!" Информация такого рода порождает в пользователе ощущение участия в процессе загрузки. Обратите внимание на важность последнего сообщения, говорящего о том, что выполнение операции завершилось успешно. Кроме того, если в процессе загрузки возникают какие-либо трудности, то текстовая информация, которая содержится в указанных обновляемых сообщениях, может помочь пользователю в преодолении возникших проблем.

При написании кода, предоставляющего пользователю периодически обновляемую информацию о степени завершения задач, которые выполняются в течение длительного времени, может потребоваться явная перерисовка элемента управления. Если не предусмотрено явное обновление форм и элементов управления, то они, как правило, лишь помещают сообщения, требующие перерисовки экрана, в очередь, непринудительное обновление сообщений на экране происходит только тогда, когда у системы находится время для их обработки. Поскольку ваш вычислительный процесс может выполняться в том же потоке, что и код пользовательского интерфейса, выполнение полезной работы будет препятствовать обработке сообщений, помещенных в очередь, до тех пор, пока управление не будет возвращено пользовательскому интерфейсу. Для разрешения этой проблемы в .NET Compact Framework для каждого элемента управления предусмотрен метод Update(). Вызов этого метода приводит к немедленной перерисовке элемента управления. В листинге 11.5 представлен простой рабочий алгоритм, который периодически обновляет в элементе управления Label текст, информирующий о степени выполнения приложения. Если только не осуществить вызов label1.Update() при обновлении текста в Label, то новый текст будет отображен лишь после завершения работы. 

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

Если длительная задача выполняется в высокоприоритетном потоке (том же, в котором выполняется код пользовательского интерфейса), то предоставление пользователю возможности отменить ее выполнение, хотя и осложняется, по-прежнему остается осуществимым. Как и в случае обновления пользовательского интерфейса в процессе выполнения интенсивных вычислений, реакция на пользовательские запросы, в том числе и на щелчок на кнопке отмены выполнения, возможна лишь при условии обработки сообщений потока пользовательского интерфейса. В .NET Compact Framework предусмотрено решение для подобных ситуаций, но аналогичные концепции используются, вероятно, и в каркасах приложений для других устройств. Вызов статического метода System.Windows.Forms.Application.DoEvents() приводит к принудительной обработке всех сообщений, находящихся в очереди данного потока, до того, как выполнение сможет быть продолжено. Это означает, что будут обработаны и сообщения, требующие перерисовки пользовательского интерфейса, в том числе ожидающие обработки щелчки на кнопках и нажатия клавиш. Если вызывать метод DoEvents() достаточно часто (несколько раз в секунду), то можно обеспечить сохранение интерактивности пользовательского интерфейса без малейшего ущерба для выполнения текущей задачи.

Может показаться, что метод DoEvents() является панацеей от всех бед, но это не так. Вызывая метод DoEvents(), необходимо проявлять осторожность, поскольку при этом могут порождаться в высшей степени нежелательные тонкие эффекты. Так как вызов метода DoEvents() приводит к обработке всех сообщений, прежде чем управление будет возвращено вызвавшему его коду, то это может сопровождаться вызовом обработчиков событий таймера и повторными вхождениями в выполняющиеся в данный момент обработчики событий. В результате этого может сложиться такая ситуация, при которой мы будем иметь множество вложенных вызовов обработчиков событий, связанных с элементами пользовательского интерфейса, и таймеров, если метод DoEvents() вызывается внутри обработчика события и новое сообщение о событии помещается в очередь еще до завершения обработки первого события. Собираясь использовать метод DoEvents(), вы должны использовать при написании кода обработчиков событий своего приложения технологию "безопасного программирования" (defensive programming), которая предполагает тщательную проверку выполнения всех допустимых условий. Настоятельно рекомендуется помещать все подобные проверки в самом начале кода обработчиков событий, чтобы осуществить немедленный выход из функции в случае, если вхождение в нее является повторным. Прежде чем осуществить вхождение в блок кода, в котором выполняется задача, требующая длительного времени, и в процессе этого вызывается метод DoEvents(), убедитесь в том, что для всех элементов управления, генерация которыми событий должна быть запрещена, значение свойства Enabled установлено в false; благодаря этой мере пользователи будут лишены возможности выполнять щелчки на указанных элементах управления, тем самым загромождая очередь событий. Ситуации, в которых возможность повторного вхождения в обработчики событий является желательной, встречаются крайне редко, ибо в этом случае код становится чрезвычайно запутанным и трудно поддается отладке. Если вы можете выбирать между использованием метода DoEvents() и созданием фонового потока для выполнения основных вычислений, то я бы рекомендовал почти всегда отдавать предпочтение хорошо продуманному последнему решению. Каким бы сложным с концептуальной точки зрения ни казалось использование нескольких потоков, модель их выполнения обычно оказывается более простой и предсказуемой, чем смесь кодов каркаса и приложения, вызываемая при использовании метода DoEvents(). Ничто из вышесказанного не является чем-то специфическим для мобильных устройств; те же самые проблемы возникают и в случае настольных компьютеров, однако мы акцентируем на них внимание, исходя из повышенных потребностей конечных пользователей в отношении интерактивного взаимодействия с приложением в случае мобильных устройств. Тем не менее, иногда применение метода DoEvents() может оказаться полезным, и я описываю здесь этот подход, одновременно предостерегая вас: "Caveat emptor!" ("Пусть покупатель будет бдителен!"), то есть действуйте на свой страх и риск. Если вы покупаете билет на DoEvents(), то должны быть готовы ко всем подъемам и спускам на этом маршруте.