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

Салмре Иво

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

■ Кто будет осуществлять развертывание приложения? Будут ли это делать конечные пользователи? Знакомы ли конечные пользователи с целевыми устройствами и процедурами инсталляции? Будут ли организации развертывать приложения на устройствах своих сотрудников? Будет ли приложение развертываться оператором мобильного телефона или загружаться из 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)

Введение