Разработка пользовательского интерфейса

7.4. Тестирование на эмуляторах и физических устройствах

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

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

• Эмуляторы не приходится физически удерживать в руках. В процессе использования большинства мобильных устройств их удерживают в руке и осуществляют все необходимые манипуляции либо пальцем той же руки (при работе одной рукой), либо второй рукой. Проделать то же самое с изображением на экране невозможно.
• Мышь и клавиатура настольного компьютера могут ввести вас в заблуждение. Ввод букв в текстовом поле при помощи клавиатуры - это не то же самое, что ввод данных с использованием 12-кнопочной клавиатуры телефона. Выполнить щелчок мышью - это не то же самое, что надавить пальцем или пером в нужной точке экрана.
• Размеры вашей руки никак не учитываются при работе с компьютерным экраном. При использовании эмулятора для элементов управления пользовательского интерфейса трудно подобрать наиболее оптимальное расположение, поскольку курсор мыши имеет очень небольшие размеры и не закрывает экран при его перемещении над кнопками. Курсор мыши вообще физически ни с чем не связан. В отличие от этого перо, используемое совместно с сенсорным экраном, имеет заметные размеры и физически связано с вашей рукой, которая имеет еще большие размеры; поэтому, когда вы пытаетесь надавить на кнопку, вы непроизвольно закрываете значительную часть экрана.
• Настольные компьютеры и лэптопы обеспечивают более высокую точность указания, чем мобильные устройства. В случае настольных компьютеров вы имеете дело с плоской поверхностью экрана, где указатель отображается на той же поверхности, что позволяет вам физически увидеть, когда именно вы должны нажать кнопку. В то же время, на сенсорном экране мобильного устройства указатель мыши не отображается. "Щелчок", который осуществляется путем надавливания на экран, происходит примерно в той точке, в которой, по мнению пользователя, он должен быть выполнен, но на фактическое положение этой точки оказывает влияние смещение, зависящее от угла, под которым пользователь смотрит на экран, наличие некоторого промежутка между элементами дисплея и сенсорной поверхностью, и калибровка самой сенсорной поверхности. На практике это означает, что существует физический предел размеров элемента управления пользовательского интерфейса, ниже которого пользователь уже может "промахнуться" при надавливании на элемент.
• Эмулятор можно легко сбросить, и он не используется для других целей в промежутках между выполнением тестовых запусков вашего приложения. Эмулированный смартфон - это вовсе не тот самый телефон, который вы используете для телефонных переговоров и ведения расписания встреч. Тот факт, что физическое устройство часто предназначается не только для определенного способа его использования, но и для выполнения других функций, имеет очень большое значение. Вам необходимо убедиться в нормальной работе приложения в условиях, когда устройство функционирует в течение 24 часов 7 дней в неделю, а также попытаться понять, каким образом другие приложения, выполняющиеся на устройстве, могут влиять на ваше приложение. Добиться точной имитации такого рода реальных условий эксплуатации приложения очень трудно.

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

Несколько альтернативных вариантов компоновки экрана, более пригодных для физических устройств

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

Проектируйте код пользовательского интерфейса мобильного приложения таким образом, чтобы его можно было легко тестировать и модифицировать

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

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

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

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

Выводы

1. Использование конечного автомата для контроля функционирования элементов управления. Конечный автомат великолепно подходит для управления всеми нуждами пользовательского интерфейса мобильного приложения. Экран мобильного приложения является ценным и дефицитным ресурсом, и этот ресурс требует весьма бережливого отношения. Необходимо следить за эффективным использованием экранного пространства в процессе того, как пользователь переводит приложение из одного состояния в другое. При наличии конечного автомата, который показывает, скрывает и перемещает элементы управления по экрану в соответствии с необходимостью, эту задачу можно решить весьма эффективно. Абстрагирование всех режимов работы пользовательского интерфейса в одном конечном автомате обеспечивает максимальную гибкость процесса внесения изменений в модель экранного дисплея, избавляя вас от необходимости просматривать и изменять множество кода, распределенного между различными функциями и обработчиками событий пользовательского интерфейса.
2. Использование косвенных функций для обновления пользовательского интерфейса. Изменение информации, отображаемой на экране мобильного устройства, может осуществляться двумя способами:
   • непосредственно, путем использования встроенного кода (например, Labell.Text = newText ) и
   • косвенно (например, UpdateDownloadStatusText (newText); ).
   Преимущество косвенного подхода заключается в том, что он позволяет вашему коду отделить фактически используемый элемент управления от того обновления, которое вы хотите выполнить. Косвенная функция UpdateDownloadStatusText(newText); сегодня может обновлять элемент Labell, но, возможно, завтра вы решите, что лучше будет отобразить текст поверх растрового изображения или вывести его в виде текста, прокручиваемого в узкой полоске экрана. Например, обычной реакцией на щелчок на кнопке может быть обновление текста в ярлыке или окне списка. Вместо того чтобы выполнять это обновление непосредственно в обработчике событий кнопки, можно поступить гораздо более гибко и воспользоваться вызовом обобщенной функции UpdateXXXXXXX (), которая и выполнит всю работу. Введение промежуточной функции позволяет разорвать прочную связь между обоими элементами управления и при необходимости использовать другую реализацию одного из них. Проектируя пользовательский интерфейс своего мобильного приложения, вы должны избегать тесного связывания как элементов управления с логикой приложения, так и отдельных элементов управления, являющихся частью пользовательского интерфейса, между собой. Наличие единственного уровня косвенности позволяет устранить такое тесное связывание.

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