Наконец, гораздо проще взять инкапсулированный код и вставить его в вызывающую функцию, чем пытаться преобразовать произвольный фрагмент кода к инкапсулированному виду, чтобы повысить эффективность работы с ним. Это вам подтвердит каждый, кому хотя бы раз приходилось заниматься упорядочением кода типа "спагетти", написанного другими разработчиками, приводя его к более удобной в работе инкапсулированной форме!
В силу описанных причин при разработке программного обеспечения для мобильных устройств удачная структура кода играет, по крайней мере, не меньшую роль, чем в случае настольных компьютеров. Использование конечных автоматов облегчает эффективную организацию кода, что в свою очередь способствует созданию замечательных приложений.
Отдаете ли вы себе в этом отчет или нет, но значительная доля кода вашего приложения всегда будет связана с управлением его состояниями. Как бы то ни было, вам придется иметь дело с задачами подобного рода, и только вам решать, выбрать ли явный подход к управлению состояниями приложения или же остановиться на модели неявного управления. Явное управление состояниями имеет ряд существенных преимуществ, не самым последним из которых является то, что такой подход заставляет вас более тщательно продумывать схемы функционирования вашего приложения.
На самых ранних стадиях разработки приложений и построения их прототипов формализация этих процессов, как правило, затруднена. Это ни в коем случае не должно отбивать у вас охоту к использованию конечных автоматов. Наоборот, конечные автоматы пригодятся вам на этих стадиях не меньше, чем на более поздних. Из предыдущего рассмотрения вы уже должны были понять, что для реализации конечного автомата требуется совсем небольшой объем дополнительного кода. При этом добавление новых состояний, а также удаление и переименование существующих состояний в соответствии с изменением определений по мере разработки ваших идей не составляет никакого труда. По моему мнению, при проектировании пользовательских интерфейсов мобильных приложений конечных автоматов, позволяющие централизованным образом экспериментировать с логикой размещения и масштабирования элементов управления, оказываются особенно полезными. Даже если разработка ведется в специализированном стиле, подход, основанный на использовании конечных автоматов, поможет вам сэкономить время и обеспечит необходимую гибкость в процессе уточнения ваших идей.
Сколько конечных автоматов должно быть в приложении?
Надеюсь, к этому моменту вы уже успели убедиться в целесообразности использования конечных автоматов в качестве центральной составляющей проекта мобильного приложения. Как и в случае любого другого аспекта проектирования, существуют некоторые общие принципы создания конечных автоматов, а также важные детали реализации. Конструирование подходящих разновидностей конечных автоматов является своего рода искусством, овладение которым приходит с приобретением опыта. Конечный автомат должен служить "абстрактным представлением одной или нескольких переменных, принимающих набор конечных значений, каждое из которых отображается в полезное дискретное состояние". Эти переменные должны некоторым образом коррелировать с различными состояниями, в которых может пребывать приложение или класс. Как и в случае приведенного выше примера кода, полезно явно определить переменную типа перечисления, значения которой, получающие определенные имена, задают действительное множество состояний, которыми вы хотите управлять посредством того или иного конечного автомата.
Иногда удобно использовать несколько конечных автоматов в одном приложении. Конечный автомат, который управляет кэшированными данными, извлеченными из базы данных, может использоваться наряду с независимым конечным автоматом, управляющим такими графическими объектами, как перья и кисти, кэшируемыми для их использования в обычных задачах рисования. Третий конечный автомат может управлять выполнением задач фоновыми потоками. И хотя все перечисленные конечные автоматы можно было бы объединить в один "главный конечный автомат", такой комбинированный конечный автомат представлял бы просто формальное объединение всех возможных случаев изменения состояния приложения и не дал бы ничего нового, поскольку состояния, которыми управляют отдельные конечные автоматы, слабо или вообще не коррелируют друг с другом. Точно так же, возможна крайность другого рода, когда вместо создания одного конечного автомата, выполняющего всю работу, предпочитают иметь десятки небольших конечных автоматов, каждый из которых управляет отдельной переменной приложения. Роль ключа к нахождению правильного решения играет корреляция. Если можно выделить набор переменных, объектов или ресурсов, которые тем или иным образом коррелируют между собой, то управление этим набором удобно и целесообразно осуществлять при помощи одного конечного автомата.
Ниже приведены описания некоторых полезных конечных автоматов, которые вы можете использовать в своих проектах.
Конечный автомат для пользовательского интерфейса
Пользовательские интерфейсы — одна из наиболее очевидных областей, где конечные автоматы могут находить широкое применение. Поведение элементов управления, совместно использующих одну и ту же форму, часто является коррелированным; некоторые элементы управления отображаются и скрываются в одно и то же время, некоторые элементы перемещаются при отображении других элементов и так далее. С каждой из форм, которые вы конструируете, должен связываться конечный автомат, управляющий визуальным поведением формы. Если в самой форме содержится несколько страниц, например, диалоговые окна с вкладками или экраны многошаговых мастеров, которые пользователи могут пролистывать, то, вероятно, имеет смысл предусмотреть для каждой из подстраниц собственный конечный автомат.
Состояние пользовательского интерфейса формы имеет особенно важное значение в случае мобильных устройств, поскольку поверхность экрана — это дефицитный ресурс, которым необходимо разумно распоряжаться. По мере того как пользователь выполняет переходы между различными состояниями приложения, элементы пользовательского интерфейса должны отображаться и скрываться или изменять свои размеры и перемещаться в другое место, чтобы соответствующая информация всегда оставалась доступной для пользователя в любом из состояний, в которых может находиться приложение. Вполне естественно, что в экранном пространстве нуждаются различные части приложения, и если логика отображения, сокрытия или перемещения элементов управления будет растворена в логике вашего приложения, то результирующая схема управления окажется весьма запутанной. Существует настоятельная необходимость в главном арбитре, который управлял бы распределением пространства экрана, и конечный автомат великолепно подходит для этих целей.
На рис. 5.2 представлены состояния пользовательского интерфейса нашей обучающей словарной игры для Pocket PC. Верхняя часть экрана отведена игровому полю. Персонаж перемещается по игровому полю, собирая объекты, если пользователь правильно отвечает на вопросы. На схеме представлены четыре состояния приложения, а стрелками указаны возможные переходы между состояниями пользовательского интерфейса (ПИ)
Рис. 5.2. Различные состояния пользовательского интерфейса в игре с множественным выбором
Как видно из приведенной схемы, для каждого состояния имеется определенная информация, которую необходимо отобразить для пользователя, и определенная входная информация, представляющая ответы пользователя, возможность ввода которой должна обеспечиваться. В случае настольных компьютеров, размеры экранов которых достаточно велики, это не чревато какими-либо трудностями, однако в силу ограниченности экранного пространства мобильных устройств оно должно использоваться как можно более эффективно. Для вывода вопросов и ответов служат текстовые поля; кроме того, непосредственно поверх растрового изображения игрового поля выводится дополнительный текст. Пользователям предоставляются различные кнопки, с помощью которых они могут осуществлять свой выбор и переводить приложение в другое состояние. В данном примере потребовались четыре различных состояния пользовательского интерфейса.
В дополнение к этому конечные автоматы оказываются весьма полезными во время экспериментирования с пользовательским интерфейсом и его окончательной доработки. Мы смогли очень быстро протестировать всевозможные позиционные и размерные параметры благодаря той легкости, с какой можно было изменять код компоновки элементов управления при помощи конечного автомата. Так, первоначально область вывода текста располагалась над игровым полем, но тестирование показало, что для повышения удобства пользования приложением эту область лучше разместить несколько ниже, в связи с чем она смещалась и тестировалась в самых разных конфигурациях. Кроме того, были проведены эксперименты с изменением размера текстового поля, используемого для отображения информации общего характера, представляющей интерес для пользователей, в различных состояниях приложения, в результате чего была найдена оптимальная конфигурация, обеспечивающая необходимый баланс эксплуатационных и эстетических характеристик. Хотя для выполнения описанной реорганизации пользовательского интерфейса применение конечного автомата вовсе не являлось обязательным, это намного упростило работу. Расположение всего кода, ответственного за параметры видимости, размеров и размещения, в одном месте позволяет значительно сократить сроки завершения этой части процесса итеративного проектирования, и сделать ее более понятной по сравнению с вариантом, в котором упомянутый код располагается вразброс в различных местах кода, реализующего логику приложения.
