Этапы проектирования приложения для мобильного устройства

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

5.1. Анализ предметной области

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

При выполнении всех шагов, оставьте за собой возможность гибкого изменения плана разработки программного обеспечения, однако область и сценарии применения в общих чертах меняться не могут, иначе возможна ситуация когда приложение окажется слишком сложным для использования его на мобильном устройстве. Так же следует указать, что у разработчиков имеющих опыт разработки для стационарных компьютеров, может появиться соблазн переносить, возможно, уже имеющийся программный продукт для стационарного компьютера, на мобильное устройство. И это в корне не правильный подход, там, где нет стационарного компьютера, но есть потребность в функционировании информационной системы предприятия. Условия работы сотрудников, скорее всего, будут не определенными, не комфортными, а на ходу. И им не представится возможным и комфортным получение необходимой информации в течение двух или трех минут, как это часто бывает на программах для ПК. Так же укажу что 2-3 минуты это при очень хорошем раскладе дел, чаще требуется больше времени. Это и нормально, ведь человек работая за стационарным компьютером, скорее всего, будет нуждаться в высокой функциональности, обмене информацией различных приложений. Это и приводит к усложнению системы и повышения длительности работы. А человек, который работает с мобильным приложением, находится, где то в проходном и динамичном месте, сфокусировать свое внимание до получение результата на мобильное устройство представляется нормальным не более чем в течении 20-25 секунд. Это время на которое следует ориентироваться с учетом того что устройство потребуется достать из кармана, воспользоваться пером или кнопками управления. Так что перенос, популярной программы с ПК на мобильное устройство, без проработки элементов управления, обеспеченно на провал.

5.2. Разработка пользовательского интерфейса

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

Так что первое требование к пользовательскому интерфейсу

Концепция универсального пользовательского интерфейса не получила развитие в силу - выпускаемые устройства имеют различные размеры и различное предназначение. Так, по своим физическим размерам визуальный пользовательский интерфейс смартфона значительно отличается от интерфейса Pocket PC. В то же время, каждый из этих интерфейсов значительно уже отличается от интерфейса планшетного компьютера. Эти различия вовсе не произвольны и обусловлены тем, какой именно способ ношения устройства предполагается (например, в кармане брюк, кармане пиджака, в рюкзаке или портфеле), и в каких ситуациях оно должно использоваться. Размеры экрана влияют на способы представления информации и на то, какие элементы управления будут использованы. Так же механизма ввода информации отличаются от устройства к устройству, а значит и элементы графического интерфейса, скорее всего тоже окажутся разными. Такие устройства, как смартфоны, снабжены расширенной 12-клавишной клавиатурой, но экранные указатели для них не предусмотрены, тогда как устройства PDA (персональные помощники) в качестве основного механизма ввода оборудуются сенсорным экраном. Достоинства и недостатки устройств с сенсорным экраном приведены в таблице 5.1

Справедливости ради необходимо указать что бывают:

В подтверждение того что для устройств с сенсорным экраном разработать интерфейс проще, можно привести набор элементов управления .net compact framework в таблице 5.2.

Сравнение элементов управления для устройств с сенсорным экраном и без него в .NET Compact Framework

Windows Standart 6 (без сенсорног экрана)	Windows Standart 6 (с сенсорным экраном)

Большое разнообразие устройств, не позволяют создать технологию масштабирования пользовательского интерфейса. Однако существуют рекомендации от различных фирм, которым следует уделить пристальное внимание рекомендациям разработки интерфейса целевого устройства. Если их, конечно, опубликуют соответственно фирмы производители, возможно простое изучение имеющихся программ в стандартной поставке с устройством. Изучение программ из стандартной поставки позволит вам сохранить культуру использования элементов управления в вашем приложении по отношению к тому устройству, на котором предполагается эксплуатация. А так же следует изучить рекомендации компании Microsoft на следующей странице http://msdn.microsoft.com/en-us/library/bb677147.aspx.

Каждая категория устройств характеризуется своим оптимальным набором задач и моделей использования, для которых она предназначена. Мобильные телефоны используются главным образом для того, чтобы вести телефонные разговоры, просматривать ранее введенную информацию и вводить небольшие объемы новой информации, обычно - в виде одной-двух текстовых строк или простых наборов чисел. Интерфейсы устройств категории Pocket PC в состоянии предложить большие возможности дисплея для исследования информации, однако, так как в основном они выпускаются без встроенной клавиатуры, они не приспособлены для ввода текста в свободной форме. Устройства Pocket PC Phone достаточно удобны для ведения телефонных разговоров, но если такое устройство используется пользователем только для этого, то его выбор был неверным.

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

Одна рука или две?

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

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

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

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

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

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

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

Другим существенным фактором навигации в пределах приложения является то, каким пользователи видят все устройство в целом. В процессе использования смартфонов их пользователи склонны воспринимать устройство как "одно приложение" в большей степени, чем пользователи Pocket PC или Tablet PC. На смартфонах концепция запуска приложений или переключения между ними отражена слабо; вместо этого пользователь представляет себе все происходящее как переключение между различными экранами устройства. Вследствие такого размытия границ приложения важность следования привычным моделям навигации в подобных ситуациях еще более возрастает. В общем случае можно полагать, что чем меньше размеры устройства, тем в большей степени пользователь будет воспринимать его как единое приложение и поэтому рассчитывать на единообразное поведение всех средств навигации, используемых на этом устройстве.

В отличие от смартфонов устройства Pocket PC ориентированы на то, что ими будут манипулировать двумя руками. Одна рука держит устройство, тогда как второй рукой осуществляют навигацию и выбор нужного варианта. Если приложение предназначено для выполнения на устройствах типа Pocket PC, оборудованных сенсорным экраном и пером в качестве средств ввода, то проект целесообразно сориентировать на оптимальное использование форм-факторов механизмов ввода и вывода. Как ранее уже отмечалось, выбор устройства может определяться тем, создание какой пользовательской среды вы хотите обеспечить своим приложением.

Работая с устройствами, в которых применяется сенсорный экран, необходимо тщательно продумывать размещение элементов пользовательского интерфейса. Необходимо позаботиться о том, чтобы пользователь, работающий пером, не закрывал важные участки экрана, когда его рука скользит над экраном в процессе выбора предлагаемых вариантов; в случае смартфонов такой проблемы не существует, поскольку оперирование только одной рукой гарантирует, что экран всегда остается на виду. В отличие от пользовательских интерфейсов смартфонов метафора вкладок часто служит весьма удобной моделью пользовательского интерфейса для приложений Pocket PC, поскольку размеры экрана в этом случае достаточно велики для того, чтобы отобразить на них навигационные вкладки, а сенсорная природа экрана обеспечивает возможность быстрого перехода с одной вкладки на другую.

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

В результате внимательного исследования возможности создания универсального интерфейса, ясно, что универсальный интерфейс не достижим. Но вполне вероятно, что потребуется установить на устройства, имеющие различные цели приложения с одним назначением, а значит, потребуется разрабатывать приложение с почти единой логикой, но разными интерфейсами, которые желательно автоматически адаптировать во время установки. Так же следует понимать, что с изменением интерфейса, вероятно, частично изменится и логика программы, но все же общие наработки останутся. И иметь представление то, как вы будет адаптировать ваше приложение в случае, необходимости инсталляции его на другие устройства. Поэтому всегда настраивайтесь на специализацию интерфейса типа устройства, области применения и людей которые будут с приложением работать. В подтверждение сказанному можно привести исследования Марике де Моойи из Нидерландов. Потребители, обладая достаточным уровнем доходов, тянутся к одним и тем же технологичным вещам. Однако используют их по-разному, в зависимости от того, в какой стране они живут и к какой культуре принадлежат Исследование также показало, что культурные традиции оказывают влияние на Web и прочие пользовательские интерфейсы. WuKong, прототип КПК/телефона, разработанный компанией Sony Ericsson. Являясь полностью китайской версией, созданной для китайских пользователей, не только использует китайские иероглифы, но и оперирует отличительными фундаментальными метафорами - не документами, приложениями и папками, а людьми, отношениями и знаниями, причем под знаниями понимается лучший опыт (сценарии действий) вкупе с традиционной мудростью. Локализация, включающая перевод на местный язык, и адаптация под конкретный тип устройств необходима, но этого может, оказывается недостаточно.

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

5.3. Разработка модели данных

Введение в модели доступа к данным, используемые в мобильных приложениях

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

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

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

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

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

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

Для мобильных приложений вопрос о выборе модели доступа к данным оказывается непосредственно связанным с вопросом о выборе модели управления памятью в гораздо большей степени, чем в случае приложений для настольных компьютеров. Если памяти, необходимой для обслуживания потребностей обеих моделей, едва хватает, то это может серьезно сказаться на производительности приложения. Аналогично средствам для работы с XML-данными, существуют низкоуровневые API-интерфейсы, не использующие состояния, и высокоуровневые программные модели доступа к памяти, предлагающие более развитые возможности, но кумулятивно изменяющие состояние в процессе выполнения. Использование высокоуровневых моделей доступа к данным позволяет сократить сроки написания кода, однако за это приходится платить увеличением объема памяти, используемой для хранения информации о состоянии. Если эта информация действительно нужна и используется мобильным приложением, а объем данных, которыми при этом приходится оперировать в памяти, можно поддерживать на низком уровне, то привлечение стратегий доступа к данным, основанных на использовании состояний, является оправданным. И наоборот, если объем данных, которые приходится хранить в памяти, велик или необходимость в дополнительных возможностях, предоставляемых высокоуровневой моделью программирования, отсутствует, то разработчик, выбравший этот путь, будет только напрасно тратить драгоценную память мобильного устройства. Часто хранение тех же данных можно организовать гораздо более эффективным образом за счет отказа от универсальной программной модели доступа к данным и использования наборов типов, специально предназначенных для работы с конкретными данными, которыми необходимо управлять. Неэкономное использование памяти окажет значительное отрицательное влияние на производительность мобильного приложения; при этом проблемы производительности проявятся либо немедленно, либо впоследствии, когда вы попытаетесь ввести в приложение дополнительную функциональность, поскольку для организации поддержки новых средств вам просто не хватит резерва производительности. По возможности, старайтесь избегать излишнего усложнения приложения.

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

5.4. Развертывание мобильного приложения

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

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

Поскольку детали упаковки и развертывания приложений определяются спецификой используемых типов устройств и программных технологий, приводится лишь краткий обзор вопросов, имеющих отношение к данной теме. Отдельные шаги процедуры упаковки различны для различных технологий: J2ME/J2SE, .NET Compact Framework и ряд технологий, основанных на использовании собственных кодов, требуют для упаковки и развертывания приложений выполнения разных последовательностей шагов. Для разных типов устройств, например, PDA, смартфонов или каких-либо специализированных устройств, предусмотрены различные процедуры инсталляции программного обеспечения, отличающиеся своими деталями. Выдавая своим пользователям телефоны, операторы сетей мобильной связи часто предлагают программное обеспечение, предусмотренное для динамической загрузки на эти устройства; у этих операторов имеются собственные стратегии установки и инициализации программного обеспечения. Комплекты документации, соответствующие различным технологиям устройств и операторам сетей мобильной связи, часто можно загрузить из Web.

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

Чтобы развертывание мобильного приложения прошло успешно, вы должны дать ответы на следующие вопросы:

Все эти вопросы подробно рассматриваются в соответствующей лекции.