(неудачный пользовательский интерфейс — ежедневный источник раздражения)

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

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

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

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

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

Рис. 4.3. Проектирование моделей данных и памяти, ориентированное на достижение высокой производительности

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

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

(неудачная модель — заведомо низкую производительность)

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

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