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

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

Рис. 4.5. Пересмотрите предыдущие шаги проекта, если это необходимо для устранения проблем производительности

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

■ Остаются ли в силе намеченные вами первоначальные ключевые сценарии и набор возможностей приложения или они должны быть переопределены?

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

■ Работоспособна ли базовая модель данных, в соответствии с которой объекты загружаются в память и выгружаются из нее? Обеспечивает ли она масштабирование до тех реальных объемов данных, с которыми столкнутся ваши пользователи? Будет ли эта модель вести себя достаточно стабильно в процессе того, как пользователь своими действиями заставит приложение побывать во всех возможные состояниях, запросит дополнительные данные или запустит приложение, предоставив ему возможность выполняться непрерывно в течение многих недель?

■ Удовлетворяет ли коммуникационная модель мобильного приложения вашим требованиям? Используете ли вы наивысший из уровней абстракции API- интерфейсов и форматов файлов, который является для вас приемлемым?

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

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

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

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

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

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