Текст книги "Программирование мобильных устройств на платформе .NET Compact Framework"
Автор книги: Иво Салмре
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 14 (всего у книги 69 страниц)
В случае мобильных устройств процесс пакетирования и установки приложения часто называют инициализацией, или подготовкой к работе. Этот шаг должен быть отнесен к категориям, числящимся под рубрикой "последние по порядку, но не менее важные", поскольку, как и все остальные шаги, его корректное выполнение также требует применения итеративного подхода. Следует обязательно продумать, какие компоненты должны быть развернуты, чтобы ваше приложение могло выполняться на целевых устройствах, каким образом пользователи должны это осуществлять и какие способы будут использоваться впоследствии для обновления приложения. Ниже приведен перечень вопросов, давая ответы на которые вам будет легче выработать стратегию инициализации вашего мобильного приложения:
■ Какие модули развертываются вместе с приложением? Представляет ли собой приложение единственный двоичный исполняемый файл или имеются дополнительные файлы данных, устанавливаемые вместе с ним, например, изображения, текстовые файлы или файлы баз данных? Должен ли и может ли любой из этих файлов быть включен в двоичный файл приложения в качестве ресурса для упрощения процесса развертывания? Требуются ли приложению другие библиотеки времени выполнения или компоненты, подлежащие установке вместе с ним на устройстве?
■ Какая процедура используется для развертывания приложения на устройстве? Устанавливается ли приложение на самом устройстве через сетевое соединение? Устанавливается ли оно через настольный компьютер, с которым устройство связано кабелем? Устанавливается ли оно с карты, вставляемой в устройство? Устанавливается ли приложение с одного устройства на другое посредством инфракрасного порта, облегчающего распространение приложения между равноправными устройствами?
■ Кто будет осуществлять развертывание приложения? Будут ли это делать конечные пользователи? Знакомы ли конечные пользователи с целевыми устройствами и процедурами инсталляции? Будут ли организации развертывать приложения на устройствах своих сотрудников? Будет ли приложение развертываться оператором мобильного телефона или загружаться из Web?
■ Как будут создаваться новые версии приложения? Будет ли приложение само проверять необходимость своего обновления за счет использования сетевого ресурса? Будет ли сервер сканировать устройства, чтобы определить, нуждаются ли они в установке новой версии? Будут ли новые версии приложения устанавливаться при помещении устройства в лоток ПК?
■ Могут ли возникнуть проблемы защиты приложения? При широком развертывании любого приложения всегда возникают вопросы, связанные с его защитой, которые обязательно следует рассмотреть. Должно ли приложение снабжаться цифровой подписью? Должны ли данные, с которыми работает приложение, быть тем или иным способом защищены? Что может произойти с данными, если устройство, на котором хранятся данные, будет утеряно или украдено?
Поскольку существует бесчисленное множество всевозможных мобильных устройств и разработанных для них сетевых моделей, ни на один из поставленных выше вопросов невозможно дать единственный правильный ответ. Какое решение будет наилучшим, зависит от типа устройства, способа его подключения к сети, опытности пользователя и политик, которые сетевые операторы могут использовать для контроля доступа к устройству.
План инициализации приложения следует записать на бумаге и добавить в список сценариев. Также крайне желательно включать разработку и проверку корректности процедуры пакетирования и установки приложения в реальных условиях в состав контрольных этапов начальных стадий проекта. Современные инструментальные среды разработки могут прекрасно справляться с задачей установки приложения на устройстве в целях тестирования, но при самостоятельной установке приложения конечными пользователями среда разработки для этих целей обычно не применяется. Как показывает практика, развертывание приложения конечными пользователями всегда является проблемой.
Резюме
Хорошо известна старая, проверенная временем истина: "Лучше хорошо выполнить посредственный план, чем иметь самый хороший, детально проработанный план, который так и остается нереализованным". Эта истина применима и к разработке современного программного обеспечения. Что толку от того, что у вас имеются разработанные по всем правилам план и методология, если они недостаточно гибки, чтобы их можно было приспособить к реалиям итеративного характера получения конечного результата. "Для разных проектов разработки требуются разные уровни строгости и опыта" – вот лучшее руководство к пониманию того, какая степень формализации обернется наибольшей выгодой для проекта. Кроме того, следует быть постоянно готовым к любым неожиданностям. По мере того как вы будете разрабатывать и тестировать приложение, обязательно будут выявляться факторы, которые вынудят вас существенно изменять свои планы. Всегда учитывайте это и организуйте процесс разработки таким образом, чтобы он позволял справляться с подобными ситуациями. Итак, в хронологическом порядке:
1. Вооружитесь определенной методологией разработки и строго придерживайтесь ее. Одна из этих методологий была представлена в общих чертах в этой главе и рассматривается более подробно в последующих главах. Эта методология хорошо приспособлена для мобильных устройств. Если окажется, что ваши потребности несколько отличаются, можете изменить ее, но в любом случае вы должны действовать в соответствии с определенной методологией.
2. Подготовьте единственный основной документ проекта, который определяет ваши цели и позволяет отслеживать степень выполнения проекта. Уровень формализации этого документа будет зависеть от того, что собой представляет ваша организация. Если вы – индивидуальный разработчик, работающий автономно, то этот документ будет просто помогать вам отслеживать разработку высокоуровневых задач и сценариев, определять ваши контрольные точки в процессе решения этих задач, а также отслеживать невыполненные пункты, подлежащие дополнительному анализу; объем такого документа не должен превышать нескольких страниц. В случае если у вас крупная организация, этот документ может представлять собой официальный контракт между вами и другой организацией, в котором подробно описывается, что именно должно быть выполнено, и какие проектные решения были приняты, а также детализированы контрольные этапы проекта и его состояние на протяжении всего периода разработки. В соответствии с этим документом и должна осуществляться разработка, и вы все время должны поддерживать его "актуальность". Пусть это будет единственный документ, который представляет задачи вашего проекта и позволяет объективно оценивать этапы его выполнения.
3. Идентифицируйте контрольные точки, для которых четко определены критерии их выполнения. Это лучший способ помочь вам и участникам группы разработчиков быть честными перед самими собой при оценке результатов вашей работы. Набор четко определенных контрольных точек, которые позволяют оценивать степень завершения разработки приложения и решения поставленных задач, – бесценная вещь, независимо от того, работаете ли вы один или в составе большой организации. Достоинства контрольных точек (этапов) просто невозможно переоценить. Если вы не совсем хорошо представляете себе, какое количество контрольных точек является оптимальным, рекомендую начать с пяти. Если вам не удается разбить свой проект на пять поддающихся оценке шагов, то либо ваш проект настолько тривиален, что его можно выполнить буквально за пару дней, либо вы были недостаточно старательны при определении этапов. Пять шагов – это разумное количество для начала, которое позволит достаточно подробно анализировать степень вашего прогресса. В случае более крупных проектов может оказаться желательным дополнительное разбиение этих контрольных точек на ряд более мелких; в случае менее крупных проектов вы можете обойтись четырьмя контрольными точками, но старайтесь не использовать меньшее их количество. Введение контрольных точек выполняет три основные функции: 1) они позволяют вам объективно оценивать продвижение к намеченным целям; 2) они обеспечивают возможность пересмотра намеченных целей и контрольных точек в будущем с учетом всего нового, что вы узнаете в процессе работы над проектом; 3) завершение контрольной точки дает формальный повод критически проанализировать проведенную работу, подчистить код и скорректировать проект с учетом любых подходящих рационализаторских предложений. Без введения контрольных точек и доводки их конечных результатов существует риск того, что вы будете непрестанно заняты одним только написанием кода, и все ваши решения относительно этого будут носить исключительно тактический характер. Полученный код будет представлять собой сплошное "спагетти", сопровождение которого будет весьма затруднительным. Даты контрольных точек можно устанавливать, а можно и не устанавливать; чем многочисленнее группа разработчиков, тем большую значимость приобретает установление контрольных дат. Самое главное, чтобы все участники приходили к финишной линии текущей контрольной точки вместе, и только после этого переходили к выполнению очередной контрольной точки. Контрольные точки – ваши друзья, используйте их!
4. Руководствуйтесь требованиями производительности. В случае приложений для мобильных устройств из множества критериев безраздельное первенство принадлежит удобству использования, а главное влияние на этот аспект приложения оказывает его производительность. По мере продвижения работы над проектом проблемы производительности, решение которых оставлено "на потом", будут только усугубляться, и это является непреложной истиной. Используемые при построении мобильных приложений модели характеризуются ограниченностью доступных объемов памяти и ресурсов, что существенно отличает их от более гибких моделей, используемых в случае настольных компьютеров. Установите для себя жесткие правила во всем, что связано с обеспечением высокой производительности приложения и его интерактивных возможностей, и удерживайте весь процесс разработки в русле этих требований, Свяжите решение проблем производительности с критериями завершения контрольных точек. Именно производительность будет окончательно решать, на что способно ваше мобильное приложение. Привлекательной серебряной блесткой на фоне этой темной тучи, витающей над всем процессом разработки, является то, что сформулированная выше цель вполне достижима. Это становится возможным при наличии строго продуманного плана работ, соблюдения определенной дисциплины в процессе разработки и творческого подхода к решению возникающих проблем. Разработчики, умонастроение которых подчинено привычкам, выработанным при создании приложений для настольных компьютеров, столкнувшись с проблемами производительности, могут решить, что в невозможности реализовать то, что им хотелось, виноваты собственно устройства. Однако, по большому счету, в подобных случаях все объясняется недостатком воображения у разработчика. При хорошо продуманном пользовательском интерфейсе, правильно подобранных моделях данных и памяти, а также разумном выборе коммуникационной модели существует мало задач, решение которых не может быть обеспечено современными приложениями для мобильных устройств
ГЛАВА 5
Наш друг конечный автомат
state [`stAt]
Функция: существительное
Использование: часто в качестве определения
Этимология: средневек. англ. stat, от устар. фр. и лат.; устар. фр. estat, от лат. status, между stare и stand – ближе к STAND
Дата: 13 столетие
1а: режим или условие нахождения <в состоянии готовности> b (1): настроение ума или темперамент <во взвинченном состоянии> (2) пребывание в необычном напряжении или волнении
2а: период или стадия физического существования чего-либо
(www.m-w.com, 2004)
ma-chine [mashEn]
сущ. (мн. ma-chines)
Использование: часто в качестве определения
1. механическое устройство: устройство с движущимися частями, часто приводимое в действие электричеством и используемое для выполнения некоторой работы, особенно той, которую иначе надо было бы выполнять вручную
стиральная машина
(Encarta 2004, Quotations)
Введение
Конечный автомат (state machine) (который называют еще и машиной состояний) – весьма полезная концепция, которую удобно использовать для структурирования приложений. Продуманное использование конечных автоматов облегчает организацию и сопровождение как логики пользовательского интерфейса, так и логики приложения. Благодаря этому ваш код будет более гибким и надежным, причем это относится к разработке не только мобильных, но и вообще любых приложений. Поскольку мобильные приложения должны использовать пространство экрана и системные ресурсы эффективно и экономно, конечные автоматы оказываются особенно полезными при разработке мобильного программного обеспечения. Конечные автоматы могут быть использованы для управления тем, какие наборы ресурсов следует удерживать памяти в любой момент времени, а также тем, какие элементы пользовательского интерфейса должны находиться на тех или иных участках экрана мобильного устройства. Конечные автоматы идеально подходят для решения такого рода задач.
В данной главе вводятся и исследуются методы использования конечных автоматов, и объясняется то, каким образом применение конечных автоматов может способствовать написанию эффективного и надежного кода.
Что такое конечный автомат?
Каждый, кто прослушал курс цифровых логических схем, должен быть хорошо знаком с понятием "конечный автомат". В этой книге используется упрощенный вариант определения конечного автомата. Если прежде с конечными автоматами вам сталкиваться не приходилось, то знайте, что ничего особо сложного в этом нет, и вполне вероятно, что принцип работы конечного автомата сразу же покажется вам интуитивно понятным.
"Состояние" вашего приложения может быть определено как совокупность значений всех его переменных. Значения всех переменных приложения представляют уникальное состояние, которое изменится лишь в результате воздействия какого-либо внешнего события. Примерами подобного рода событий, способных изменить состояние приложения, являются такие события, как нажатие кнопки пользователем, событие, запускаемое при получении сообщения, или же событие таймера. В любой момент времени ваше приложение находится в каком-то определенном состоянии. В результате возмущения этого состояния приложение переходит в другое состояние. Для определения следующего состояния вашего приложения используется его текущее состояние плюс новые входные данные.
Конечный автомат является средством формальной структуризации этой реальности. Вместо того чтобы использовать все переменные приложения в качестве расширенного определения его состояния, конечный автомат создает единственную переменную, в которой хранится информация о некоем важном аспекте состояния приложения. Такой переменной обычно является элемент перечисления (например, int m_myApplicationState) некоторого множества действительных состояний, определяемого глобально или на уровне класса. Мощь подхода, использующего конечный автомат, обусловлена тем, что он позволяет в явном виде определить действительные состояния для некоторого аспекта вашего приложения и задать соответствующие варианты поведения при переходах приложения из одного состояния в другое.
У приложения может быть несколько конечных автоматов, для каждого из которых определяется собственный набор вариантов поведения приложения, подлежащих структуризации. Приложение, для которого конечные автоматы не определены, в действительности является приложением с множеством конечных автоматов; каждая переменная, определенная на уровне приложения, по сути дела сама является конечным автоматом, и любой код может получить доступ к состоянию и изменить его. Конечные автоматы используются для формирования набора взаимосвязанных переменных или вариантов поведения и их логической организации, облегчающей обработку состояний. Конечные автоматы – суть организованное поведение.
На рис. 5.1 в схематическом виде представлен конечный автомат обучающей игры, позволяющей изучать иностранные слова путем выбора одного из предлагаемых вариантов ответа. Поведение приложения разбито на пять логических состояний. Эти логические состояния существуют независимо от того, будут ли они выбраны нами для введения их определений в конечный автомат. Конечный автомат – это просто формальное описание того, как работает приложение. Она позволяет нам ясно представлять себе различные состояния, в которых может находиться приложение в процессе взаимодействия с ним пользователя.
Другим способом представления состояний приложения является построение диаграммы переходов. Эта диаграмма содержит список дискретных состояний, в которых может находиться приложение, а также возможные варианты переходов между состояниями. Список возможных состояний и вариантов перехода из одного состояния в другое для нашего приложения представлен в табл. 5.1.
Рис. 5.1. Конечный автомат для простой обучающей игры, предназначенной для изучения иностранных слов путем выбора правильного ответа из нескольких предложенных вариантов
Таблица 5.1. Варианты изменения состояний для словарной игры с множественным выбором
| StartScreen | Пользователь выбрал вариант "Next Question" | AskQuestion |
| StartScreen | Пользователь выбрал вариант "Correct Answer" | Запрещенный переход! |
| StartScreen | Пользователь выбрал вариант "Incorrect Answer" | Запрещенный переход! |
| StartScreen | Пользователь выбрал вариант "End Game" | Запрещенный переход! |
| AskQuestion | Пользователь выбрал вариант "Next Question" | Запрещенный переход! |
| AskQuestion | Пользователь выбрал вариант "Correct Answer" | CongratulateUser |
| AskQuestion | Пользователь выбрал вариант "Incorrect Answer" | ScoldUser |
| AskQuestion | Пользователь выбрал вариант "End Game" | Запрещенный переход! |
| CongratulateUser | Пользователь выбрал вариант "Next Question" | AskQuestion |
| CongratulateUser | Пользователь выбрал вариант "Correct Answer" | Запрещенный переход! |
| CongratulateUser | Пользователь выбрал вариант "Incorrect Answer" | Запрещенный переход! |
| CongratulateUser | Пользователь выбрал вариант "End Game" | StartScreen |
| ScoldUser | Пользователь выбрал вариант "Next Question" | AskQuestion |
| ScoldUser | Пользователь выбрал вариант "Correct Answer" | Запрещенный переход! |
| ScoldUser | Пользователь выбрал вариант "Incorrect Answer" | Запрещенный переход! |
| ScoldUser | Пользователь выбрал вариант "End Game" | StartScreen |
НА ЗАМЕТКУ
Я решил привести в таблице все возможные перестановки переменных, указанных в столбцах "Состояние" и "Внешний ввод", чтобы проиллюстрировать тот факт, что не любое изменение состояния разрешено. Переходы между состояниями, указанными в строках, для которых в столбце "Следующее состояние" содержится пояснение "Запрещенный переход!", недопустимы в нашем приложении. Если приложение пытается каким-либо образом осуществить такое изменение состояния, значит, в логике его выполнения присутствуют ошибки. В случае если предпринимается попытка выполнения недействительного перехода, логика конечного автомата должна возбуждать исключение или, по крайней мере, использовать оператор ASSERT в режиме отладки. Явная идентификация запрещенных переходов между состояниями облегчает отладку приложений.
В листинге 5.1 представлен код, реализующий определенный выше конечный автомат. Этот код соответствует диаграмме переходов, представленной в табл. 5.1 и на рис. 5.1. Обратите внимание на то, что в приведенной ниже функции участки кода, соответствующие различным изменениям состояний, содержат вызовы функций, отключенные с помощью символов комментариев. Эти функциональные вызовы представляют ту часть работы, которая должна быть выполнена для соответствующего изменения состояния, и отключены символами комментариев с той целью, чтобы приведенный ниже код можно было компилировать как независимый блок; реализация вызываемых функций остается за вами. Для определения текущего варианта изменения состояния удобно использовать блок операторов switch/case.
Каждый оператор case соответствует одному из вариантов изменения состояния и должен содержать вызов функции, выполняющей всю необходимую для этого работу. Подобного рода централизация и инкапсуляция управления состояниями является одним из наиболее мощных аспектов использования конечных автоматов; все важные изменения состояний приложения определяются и обрабатываются централизованно в одном месте программы.
Листинг 5.1. Простой код конечного автомата для игры с множественным выбором
class MyStateMachineClass {
private enum GameState {
StartScreen, AskQuestion, CongratulateUser, ScoldUser
}
private GameState m_CurrentGameState;
//–
//Конечный автомат, воздействующий на пользовательский интерфейс
//и управляющий переходами приложения в другие состояния в соответствии
//c текущим режимом работы пользователя
//–
private void StateChangeForGame(GameState newGameUIState) {
//Определить, в какое состояние переходит приложение
switch(newGameUIState) {
case GameState.StartScreen:
//Если переход в данное состояние осуществляется из состояния,
//для которого это запрещено, возбудить исключение
if ((m_CurrentGameState != GameState.CongratulateUser) && (m_CurrentGameState != GameState.ScoldUser)) {
throw new System.Exception("Запрещённый переход!");
}
//ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:
// 1. Скрытие (Hide), отображение (Show) и перемещение (Move)
// элементов управления пользовательского интерфейса
// 2. Настройка переменных/состояния игры, соответствующих
// данному режиму работы
//
// SetUpGameStateForStartScreen();
break;
case GameState.AskQuestion:
//Если переход в данное состояние осуществляется из состояния,
//для которого это запрещено, возбудить исключение
if ((m_CurrentGameState != GameState.StartScreen)
&& (m_CurrentGameState != GameState.CongratulateUser)
&& (m_CurrentGameState !=GameState.ScoldUser)) {
throw new System.Exception("Запрещённый переход!");
}
//ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:
// 1. Скрытие (Hide), отображение (Show) и перемещение (Move)
// элементов управления пользовательского интерфейса
// 2. Настройка переменных/состояния игры, соответствующих
// данному режиму работы
//
// SetUpGameStateForAskQuestion();
break;
case GameState.CongratulateUser:
//Если переход в данное состояние осуществляется из состояния,
//для которого это запрещено, возбудить исключение
if (m_CurrentGameState != GameState.AskQuestion) {
throw new System.Exception("Запрещённый переход!");
}
//ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:
// 1. Скрытие (Hide), отображение (Show) и перемещение (Move)
// элементов управления пользовательского интерфейса
// 2. Настройка переменных/состояния игры, соответствующих
// данному режиму работы
//
// SetUpGameStateForCongratulateUser();
break;
case GameState.ScoldUser:
//Если переход в данное состояние осуществляется из состояния,
//для которого это запрещено, возбудить исключение
if (m_CurrentGameState != GameState.AskQuestion) {
throw new System.Exception("Запрещённый переход!");
}
//ЧТО СДЕЛАТЬ: Поместите сюда код, выполняющий следующие операции:
// 1. Скрытие (Hide), отображение (Show) и перемещение (Move)
// элементов управления пользовательского интерфейса
// 2. Настройка переменных/состояния игры, соответствующих
// данному режиму работы
//
// SetUpGameStateForScoldUser();
break;
default:
throw new System.Exception("Неизвестное состояние!");
}
//Сохранить запрошенное новое состояние в качестве текущего
m_CurrentGameState = newGameUIState;
}
} //Конец класса
