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

7.1. Возрастание роли навигационных средств при уменьшении экранного пространства

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

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

В табл. 7.1 приводятся сравнительные характеристики дисплеев настольных компьютеров, а также устройств Pocket PC и Smartphone. Большинство современных дисплеев для настольных компьютеров имеют размеры свыше 1024x768 пикселей, тем самым предоставляя для отображения информации большое экранное пространство.

Относительные размеры экранов различных устройств

Тип устройства	Типичное разрешение	Количество пикселей	Относительный размер
Настольные компьютеры / ноутбуки	1024x768	786432	100%
Pocket PC (устройства с сенсорным экраном)	240x320	76800	9,77%
Смартфоны	176x220	38720	4,92%

Размеры типичного дисплея Pocket PC обеспечивают менее 10% площади экрана, предоставляемой дисплеями настольных компьютеров с низким и средним разрешением или дисплеями лэптопов. Величина этого показателя для смартфонов составляет 5%.

Это не столь ужасающе, как могло бы показаться, по следующим причинам:

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

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

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

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

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

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

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

Пользовательский интерфейс может находиться в одном из двух режимов:

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

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

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

7.2. Списки или вкладки?

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

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

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

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

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

На рис 7.1 представлен основанный на использовании вкладок интерфейс устройства с сенсорным экраном, позволяющий осуществлять навигацию по интерфейсу переводчика, предназначенного для перевода слов общего; каждая вкладка предлагает направление перевода. Первая вкладка предполагает перевод с английского на русский, а вторая вкладка предполагает перевод с русского на английский. Клавиша TR обеспечивает перевод, а клавиша back является аналогом backspace для обычной клавиатуры ПК (удаляет символ стоящий перед курсором).

(рис 7.1) Приложение демонстрирующее удобство вкладок

Данное приложение имеет две вкладки, каждая из которых переводит текст, но различных направлениях. Удобство такого переводчика заключается в возможности просматривать перевод слов по двум направлениям, т. е. пользователю предоставляется возможность перевести с английского на русский и, не потеряв набранное слово, перевести с русского на английский. Так же возможно будет удобным предоставить возможность создавать вкладки с нужным направлением перевода, что позволит пользователю перевести, например, сразу 3-4 слова с английского на русский. И просматривая возможные их значения (слово переводится однозначно весьма редко), понять смысл того что переводит. Как видите, если бы не использовались вкладки, то пользователю пришлось набирать все три слова подряд, и ему было бы необходимо запоминать 3-4 множества слов соответствующих каждое своему слову. Данное требование не совсем было бы уместно, если понять что человек, использующий эту программу находится где-нибудь за границей и его внимание наверняка и так рассеянно, а значит, пользователь не запомнит эти множества и будет, раздражаясь набирать вновь уже набранные слова. А вкладки в данном случае являются удобным решением данной задачи.

Пользовательские интерфейсы мобильных телефонов и важность соблюдения единообразия в использовании клавиш

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

7.3. Сенсорные экраны и важность использования крупных кнопок

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

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

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

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

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

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

На рис 7.2 (Пример неэффективного использования программной клавиатуры) показано то же самое приложение, в котором используется программная клавиатура (software input panel - SIP). Хотя программная клавиатура представляет собой в целом неплохой механизм для ввода букв, цифр и символов, укрупненные элементы управления пользовательского интерфейса, предназначенные специально для переводчика, применяемого при переводе обще бытовых слов. Типовая программная клавиатура удобна для ограниченного ввода информации общего назначения, но ее можно и необходимо улучшать в тех случаях, когда задаче требуется более специфический ввод. Проектируя пользовательские интерфейсы для устройств с сенсорными экранами, вы должны делать размеры элементов управления настолько большими, а их целевое назначение настолько специализированным, насколько это возможно.

Оптимизируйте ввод обычных данных

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

(рис 7.2) Пример неэффективного использования клавиатуры

Далее снова приведен пример более эффективного использования пространства (рис 7.3). В переводчике не требуется учет регистра, не нужны цифры и специальные символы. А значит, от ненужных символов следует отказаться, следовательно, и количество кнопок будет и их представится возможным сделать крупнее. Более того обращаю ваше внимание на то что кнопки на русском и английском языке, повторяют клавиатуру обычного ПК. И не смотря на то, что в английском языке, на семь букв меньше. Клавиши своего расположения не изменили. Может возникнуть соблазн, увеличить кнопки английского интерфейса, за счет удаления ненужных клавиш. Но важно помнить, в итоге длительного использования программы, у человека выработается мышечная память, и ему придется прилагать некоторые усилия что бы, например, при переводе с английского на русский, не нажимать, так как, будто он используют клавиши перевода с русского на английский. Именно в связи с этим не была преобразована английская клавиатура. Ко всему сказанному следует добавить использование программной клавиатуры (software input panel - SIP), осложняет использование вкладок. Так как вы видите, что они накрываются программной клавиатурой, а значит использовать её будет не совсем уместно.

(рис 7.3) Приложение со специальной клавиатурой, которая значительно эффективнее

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

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

На рис 7.4 и рис 7.5 приведены два возможных интерфейса, данной программы. На рис 7.4 предполагается что пользователь вносит все данные в элементы TextBox используя программную клавиатуру (software input panel - SIP). А на рис 7.5 уже заложено что пользователь может внести город, улицу и дом используя выпадающие списка ( ComboBox ). Безусловно для того чтобы использовать элементы ComboBox необходимо будет выяснить и четко решить в каких городах компания "Ваша еда" работает. Далее узнать все улицы всех городов. А потом уже выяснить какие номера домов имеются на каждой улицы каждого города. Необходимо создать и отработать механизм, который не позволит, выбрать улицу в городе Абакан из города Саяногорск. И это не малый объем работы, который следует проделать. Пользователю будет на много удобней выбирать город и остальные данные из элементов ComboBox. Что снизит значительно вероятность ошибок самого пользователя и упростит управление оператору. Которому не придется выяснять а существует та или другая улица в данном городе. Конечно знать заранее контактные данные невозможно. И потому здесь без элементов TextBox не обойтись, но все же можно обеспечить возможность делать заказ на заранее определенные наборы данных.

(рис 7.5) Форма содержащая исключительно элементы TextBox(рис 7.4) Форма содержащая элементы TextBox и ComboBox

Убедитесь в том, что для механизмов автоматизированного ввода предусмотрены параллельные механизмы ввода вручную

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выводы

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

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

непосредственно, путем использования встроенного кода (например, Labell.Text = newText ) и

косвенно (например, UpdateDownloadStatusText (newText); ).

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

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