Иво Салмре - Программирование мобильных устройств на платформе .NET Compact Framework

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

Рис. 13.5. Надежное отделение логики приложения от пользовательского интерфейса

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

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

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

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

2. Формулировка вопроса. В этом состоянии мобильное приложение предлагает пользователю перевести предложенное слово. В нашем коде мы решили отображать вопрос в элементе управления TextBox, но это вовсе не является обязательным. Например, вопрос может отображаться в элементе управления Label или выводиться поверх растрового изображения игрового поля, если оно имеется. Если целевое устройство поддерживает синтезатор речи, то вопрос может задаваться даже голосом. Мы решили использовать текстовое поле, работающее в режиме только для чтения, поскольку его возможности нас полностью устраивают и позволяют без труда отображать большие объемы информации за счет использования полос прокрутки, если это потребуется. В дополнение к отображению вопроса приложение предлагает пользователю выбрать один из двух способов ответа на него. Пользователь может выбрать вариант Challenge Me! (Ну-ка, спрашивай!), если считает, что знает правильный ответ, или Can't Think of It (Ума не приложу), если нуждается в дальнейших подсказках; для каждого из этих двух вариантов выбора могут быть предусмотрены различные правила подсчета очков. Чтобы не усложнять пробный код, в нашей реализации оба варианта обрабатываются по одному и тому же принципу и перемещают пользователя в следующее состояние приложения независимо от того, какой вариант был выбран; возможно, вы захотите добавить код, который будет по- разному подсчитывать очки для этих вариантов, или просто исключите одну кнопку, если решите этого не делать. В нашей реализации мобильного приложения для представления обоих вариантов было решено использовать элементы управления Button, но, как и ранее, такое решение не является обязательным; точно так же для предоставления этих вариантов выбора можно использовать переключатели или выпадающий список, если эти метафоры являются более подходящими для целевого устройства. Какую метафору пользовательского интерфейса выбрать, зависит от природы приложения, а также от типа устройства, на котором оно будет выполняться.

3. Предоставление пользователю нескольких вариантов ответа. В этом состоянии приложения наша игра для мобильных устройств предлагает пользователю несколько вариантов ответа на заданный ему вопрос. Для пользовательского интерфейса Pocket PC мы вновь решили использовать элементы управления Button; для смартфонов более подходящими были бы, пожалуй, нумерованные окна списков. Кроме того, в этом состоянии мы решили динамически уменьшать размер элемента управления TextBox, чтобы кнопки всех вариантов выбора уместились на экране. Пользователи могут угадывать правильный ответ до тех пор, пока он не будет получен. В нашей реализации в случае выбора неправильного ответа соответствующая кнопка затеняется (для ее свойства Enabled устанавливается значение false). В логику нашего приложения также можно включить код для отображения того, что в действительности означает неверно выбранное вами слово. Поскольку, в силу ограниченности размеров текстового окна, для отображения этой информации места недостаточно, мы могли бы вывести этот текст поверх растрового изображения игрового поля; этот вариант реализации мы также оставляем на усмотрение читателя.