Введение в жизненный цикл разработки мобильных приложений

Некоторые аспекты при разработке мобильных приложений

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

Обзор

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

  1. Процесс– Процесс разработки программного обеспечения называется жизненным циклом разработки программного обеспечения (SDLC). Мы рассмотрим все этапы SDLC относительно разработки мобильных приложений, в том числе: Идею, Дизайн, Разработку, Опытная эксплуатация (Стабилизация),  Внедрение (Распространение) и Поддержку.
  2. Аспекты– Есть целый ряд отличительных аспектов, при создании мобильных приложений, особенно в отличие от традиционных веб или настольных приложений. Мы рассмотрим все эти аспекты и то, как они влияют на развитие мобильного приложения.

Этот документ предназначен для того, чтобы ответить на фундаментальные вопросы о разработке мобильных приложений, одновременно как для начинающих, так и для опытных разработчиков. Требуется комплексный подход, что бы ознакомиться с большинством из вопросов, с которыми Вы столкнетесь во время всего Жизненного цикла разработки программного обеспечения (SDLC). Однако этот документ может не быть не обязательным для всех. Если у Вас уже чешутся руки начать разработку приложений, мы рекомендуем проскочить вперед или к обучающим программам Введение в разработку для мобильных устройств,  Hello, Android или Hello, iPhone, а затем возвратиться к этому документу позже.

Жизненный цикл разработки программного обеспечения

Жизненный цикл разработки мобильных приложений практически ничем не отличается от SDLC для веб и настольных приложений. Как и в случае с ними, существуют, как правило, 5 основных фаз процесса:

  1. Начальная стадия — все приложения начинаются с идеи. Эта идея обычно дорабатывается в прочную основу для приложения.
  2. Дизайн – Задача этой фазы разработки состоит в определении Пользовательского восприятия приложения (User eXperience, UX) такого как, общий макет приложения, как это работает и т.д., а также превращение этого UX в подходящий дизайн Пользовательского Интерфейса (UI), обычно с помощью графического дизайнера.
  3. Разработка — Как правило, наиболее ресурсоёмкая фаза. Это реальное создание приложения.
  4. Опытная эксплуатация (стабилизация) Контроль качества, когда разработка уже ушла далеко вперед, как правило, начинается тестирование приложения и исправление ошибок. Некоторое время, в течении которого приложение будет эксплуатироваться в ограниченной бета-фазе, в которой более широкий круг пользователей получает возможность использовать его, осуществлять обратную связь и сообщать изменения.
  5. Внедрение (распространение).

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

Кроме того, эти фазы могут использоваться в любом количестве методологий SDLC таких как Гибкая методология разработки, Спиральная модель, Каскадная модель и т.д.

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

Начальная стадия

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

Начальная стадия —  это определение и уточнение идеи приложения. Для создания успешного приложения, важно задать некоторые фундаментальные вопросы. Например, если вы разрабатываете приложение для распространения в общественном магазине приложений (App Store, Google Play), некоторые соображения являются:

  • Конкурентное преимущество – Есть там уже подобные приложения? Если есть, то чем Ваше приложение отличается от других?

Если Вы планируете для приложения взаимодействие с уже существующими проектами:

  • Интеграция в инфраструктуру– Как приложение будет встраиваться в существующую инфраструктуру или чем будет её расширять?

Кроме того, следует оценить использование приложения в мобильном форм-факторе:

  • Возможность – Какую возможность это приложение предоставит пользователям? Как они будут использовать её?
  • Форма/Мобильность – как это приложение будет работать в мобильном форм-факторе? Как можно использовать возможность приложения с использованием мобильных технологий, таких как местоположения, камеры и т.д.?

Дизайн мобильных приложений

Как только у Вас есть замечательная идея того, что Вы хотите проектировать, следующий шаг – начать проектировать User eXperience или UX.

UX Дизайн

В UX обычно используют каркасы или макеты с помощью таких инструментов, как BalsamiqMockingbirdVisio, или просто с помощью  старых и добрых инструментов:  ручки и бумаги. UX-макеты позволяют быстро разрабатывать UX, без необходимости беспокоиться о фактическом дизайне пользовательского интерфейса:

разработка мобильных приложений

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

  1. Apple– Руководство для пользовательского интерфейса
  2. Android– Руководство по дизайну
  3. Windows Phone– Дизайн для Windows Phone

Например, у каждого типа приложения есть метафора для переключения между разделами в приложении. iOS использует таббар внизу экрана, Android использует таббар cверху экрана, и Windows Phone использует панораму:

метафора

Кроме того, сами аппаратные средства также диктуют решения для UX. Например, устройства на iOS физически не имеют кнопки «Назад», и поэтому вводится метафора Навигационного диспетчера:

Навигационный диспетчер

 

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

Форм-фактор

И из-за большого количества форм-факторов зачастую используются форм-факторы среднего размера (что-то между телефоном и планшетом), для которого вы можете настроить таргетинг.

Дизайн пользовательского интерфейса (UI)

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

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

  1. pttrns.com– (только iOS)
  2. lovelyui.com– (для iOS, Android и Windows Phone)

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

Разработка

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

Пробная эксплуатация (Стабилизация)

Стабилизация является процессом работы над ошибками в вашем приложении. Не только с функциональной точки зрения, например: «Программа выходит из строя при нажатии на эту кнопку», но и удобство использования и производительность Лучше всего начать стабилизацию как можно раньше в процессе разработки, так, что бы изменения курса смогли произойти прежде, чем они станут очень затратными.  Как правило, приложения проходят стадии: Прототип, Альфа, Бета и Релиз-кандидат. Разные люди по-разному определяют их, но они как правило, следуют следующему шаблону:

  1. Прототип– Приложение по-прежнему в стадии проверки концепции и только базовая функциональность, или отдельные части приложения работают. Основные ошибки присутствуют.
  2. Альфа– Как правило, код основного функционала завершен (разработан, но не полностью протестирован). Основные ошибки все еще присутствуют. Дополнительный функционал до сих пор может отсутствовать.
  3. Бета– Большинство функционала в настоящее время завершена и проводится окончательное выявление и исправление ошибок. Основные известные проблемы все еще могут присутствовать..
  4. Релиз-кандидат – Весь функционал завершён и протестирован. Если исключить новые ошибки, приложение является кандидатом для выпуска в мир.

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

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

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

Некоторые, наиболее популярных из этих сервисов:

  1. Testflight – Это iOS продукт, который позволяет распространять приложения для тестирования, а также получать отчеты о сбоях и информацию об использовании от ваших клиентов. Это сервис является частью iTunes Connect, и не доступен, если вы не являетесь участником программы разработчиков Apple
  2. hockeyapp.com — Предоставляет сервис тестирования для iOS, Android и Windows Phone.

Распространение

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

Xamarin.iOS и Objective-C приложения распространяются таким же образом:

  1. Apple App Store– App Store компании Apple является глобальным общедоступным интернет-хранилищем приложений, которая встроена в Mac OS X и iOS с помощью i Это, безусловно, самый популярный метод распространения приложений, который позволяет разработчикам продавать и распространять свои приложения в Интернете с очень минимальным усилием.
  2. Внутреннее распространение – Предназначено для внутреннего распространения корпоративных приложений, которые не доступны публично через App Store.
  3. Одноранговое распространение– Предназначено главным образом для разработки и тестирования и позволяет развернуть приложение на ограниченное число надлежащим образом подготовленных устройств. При развертывании на устройство через Xcode или Xamarin Studio, оно известно как развертывания ad-hoc.

Android

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

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

Это позволяет разработчикам иметь потенциально более крупный, еще более сложный канал для распространения своих приложений. Google Play — это официальное хранилище приложений Google, но есть и многие другие. Вот несколько наиболее популярных:

  1. AppBrain
  2. Amazon App Store for Android
  3. Handango
  4. GetJar

Windows Phone

Приложения Windows Phone распространяются пользователям через Windows Store. Разработчики предоставляют свои приложения в  Центр Разработки (Dev Center) Windows Phone для утверждения, после чего они появятся в магазине.

Microsoft предоставляет подробные инструкции для  развертывания приложений Windows Phone, в процессе разработки.

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

Аспекты разработки мобильных приложений

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

Для начала рассмотрим общие аспекты, а затем мы рассмотрим специфические аспекты для каждой платформы.

Общие аспекты

Многозадачность

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

Каждая платформа обрабатывает многозадачности по-своему, что мы немного рассмотрим.

Форм-фактор

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

Устройство и фрагментация ОС

Важно принимать во внимание различия устройств на протяжении жизненного цикла разработки программного обеспечения:

  1. Концепция и планирование – Поскольку различные устройства могут иметь различные аппаратные возможности, вы должны иметь в виду, что приложение, которое опирается на определенные функции, может не работать должным образом на некоторых устройствах. Например, не все устройства имеют камеры, так что если вы создаете приложение для обмена видео сообщениями, некоторые устройства могут иметь возможность воспроизводить видео, но не создавать его.
  2. Дизайн– При разработке User eXperience (UX) приложения, следует иметь в виду пропорции различных экранов и их размеров. Кроме того, при разработке пользовательского интерфейса (UI) приложения, следует рассматривать различные разрешения экрана.
  3. Разработка– При использовании какой-либо функции из кода, наличие этой функции всегда должны быть сначала протестировано. Например, перед использованием функций устройств, таких как камера, всегда вначале опросите ОС на присутствие этого устройства. Затем при инициализации функции устройства, убедитесь, что ОС в настоящее время поддерживает устройство, а затем используйте эти параметры конфигурации.
  4. Testing– Невероятно важно начать тестировать ваше приложение как можно раньше и тестировать как можно чаще на разных реальных устройствах. Поведение устройств, даже с теми же аппаратными спецификациями может очень сильно различаться.

Ограниченность ресурсов

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

Кроме того ресурсоемкие приложения, такие как игры или программы распознавания текста может серьёзно загрузить мобильный процессор и отрицательно повлиять на производительность устройства.

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

Аспекты iOS

Многозадачность

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

Специфические для устройства ресурсы

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

Некоторые старые устройства (iPhone 3G и старше) даже не поддерживают многозадачности.

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

Специфические аспекты ОС

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

Аспекты Android

Многозадачность

Многозадачность в Android имеет две составляющей; во-первых, это жизненный цикл Активности. Каждый экран Android-приложения может находится находится в разных состояниях Активности, и существует определенный набор событий, которые происходят, когда приложение находится в фоновом режиме или выходит на передний план. Приложения должны придерживаться этого жизненного цикла для создания отзывчивого и «хорошо себя ведущего» приложения. Для получения дополнительной информации обратитесь к руководству жизненный цикл Активности.

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

Множество устройств и множество форм-факторов

В отличие от iOS, которая имеет небольшой набор устройств, или даже Windows Phone, которая работает только на рекомендуемых устройствах, удовлетворяющих минимальный набор требований к платформе, Google не накладывает никаких ограничений, на каких устройствах можно запустить Android OS. Результат этой открытой парадигмы в среде устройства – множество различных устройств с очень разными аппаратными характеристиками, разрешениями и пропорциями экрана, возможностями и потенциалом.

Из-за крайней фрагментация Android устройств большинство людей выбирают наиболее популярные 5 или 6 моделей для проектирования и тестирования, и ориентируются на них.

Аспекты безопасности

Приложения в ОС Android все работают под отдельным, изолированным пользователем с ограниченными правами. По умолчанию приложения мало что могут делать. Например, без специальных разрешений, приложение не может отправить текстовое сообщение, определить состояние телефона, или даже получить доступ к Интернету! Для доступа к этим функциям, приложения обязаны указать в своем файле манифеста, какие права они хотели бы получить. При установке приложения, операционная система считывает эти разрешения, уведомляет пользователя о том, что приложение запрашивает эти разрешения, а затем позволяет пользователю продолжить или отменить установку. Это является важным шагом в модели распространения Android, из-за открытой модели магазина приложений, поскольку приложения не рассматриваются магазином, как, например, для iOS. Для получения списка разрешений для приложений см. справочную статью Manifest.Permissions в Android документации.

Аспекты Windows Phone

Многозадачность

Многозадачность в Windows Phone также имеет две составляющих: жизненный цикл для страниц и приложений, а также фоновые процессы. Каждый экран в приложении является экземпляром класса Page, который имеет события, связанные состояниями активности или неактивности (со специальными правилами обработки в неактивном состоянии или состояния «убит»). Для получения дополнительной информации см. Обзор выполнения модели для Windows, Телефон документации Обзор модели выполнения для Windows Phone.

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

Возможности устройства

Хотя аппаратное обеспечение Windows Phone является довольно однородным из-за строгих указаний, предоставленных Microsoft, все еще существуют компоненты, которые считаются дополнительными, и поэтому требуют специального рассмотрения во время программирования. Дополнительные аппаратные возможности включают в себя камеру, компас и гироскоп. Существует также особый класс низкой памяти (low-memory = 256 МБ), который требует особого внимания или разработчики могут отказаться от поддержки low-memory.

Базы данных

Обе ОС, iOS и Android содержат ядро базы данных SQLite, которое позволяет организовать сложное хранилище данных и является кросс-платформенным. Windows Phone 7 вообще не поддерживает базы данных, в то время как Windows Phone 7.1 и 8 имеет локальное ядро базы данных, к которому можно выполнять только LINQ to SQL запросы и оно не поддерживает запросы Transact-SQL. Тем не менее, существует  библиотека SQLite с открытым исходным кодом, которое может использоваться в приложениях Windows Phone, чтобы обеспечить поддержку знакомого Transact-SQL и кросс-платформенную совместимость.

Аспекты безопасности

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

Доступ приложения к функциям аппаратного обеспечения и операционной системы контролируется возможностями, перечисленными в его файле манифеста (по аналогии с Android). Манифест должен объявлять используемые функции, необходимые для работы приложения, так, что бы пользователи могли увидеть и согласиться с этими разрешениями, а также тем, что операционная система позволяет получить доступ к API. Приложения должны запрашивать доступ к функциям, таким как контакты или информация об оборудовании, камеры, местоположение, медиа-библиотека и многое другое.

Оригинал статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *