Ниже приведены описания некоторых полезных конечных автоматов, которые вы можете использовать в своих проектах.

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

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

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

Рис. 5.2. Различные состояния пользовательского интерфейса в игре с множественным выбором

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

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

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

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

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

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

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

■ Когда и при каких условиях следует освобождать память от загруженных ранее данных? 

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