Этапы разработки, тестирования и ввода в эксплуатацию мобильных приложений (Особенности тестирования мобильных приложений в целом)

Содержание:

Введение

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

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

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

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

- около 54 % пользуются скаченными приложениями;

- столько же людей заходят на сайты через мобильный телефон;

- социальными сетями через телефон пользуется около 38 %;

- 35 % людей пользуются мобильными играми;

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

В ходе поставленной цели будут решены следующие задачи:

- рассмотрены теоретические основы разработки мобильных приложений: их этапы, особенности тестирования;

- рассмотрено создание мобильного приложения с Nokia Qt SDK.

Курсовая работа состоит из введения, двух глав, заключения и библиографии.

Глава 1 Теоретические основы разработки мобильных приложений

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

Определение цели

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

Если приложение само по себе продукт (калькулятор, например), то при его разработке нужно задаться двумя вопросами: зачем оно потребителю, и как потребитель будет им пользоваться?^[1]

Если приложение — канал коммуникации для предоставления услуги (банковской или оператора связи), то возникает вторая сторона — помимо потребительских «зачем» и «как» должны быть вопросы по сервисной части — в каких типах коммуникаций приложение нужно и какие задачи оно решит для компании? Например, мобильный банк (система самообслуживания) должен повышать среднемесячные остатки на счетах клиентов, увеличивать комиссионный доход банка и обеспечивать допродажи продуктов.

Анализ требований

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

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

Найм лучшего дизайнера и опытного разработчика

Результаты этапа анализа (концепция продукта, спецификация требований) являются входящей информацией к следующему этапу — проектированию.^[2] Мы выполняем проектирование двух составляющих приложения: графический интерфейс и структура программного кода приложения. На этом этапе создаются каркас графического интерфейса (wireframes), карта экранов (screenflow), прототип низкой детализации, а также пользовательские сценарии (use cases) и дизайн кода приложения (software architecture). 

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

Критика дизайна со стороны юзабилити-специалиста

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

Юзабилити-исследование^[3] — супер-шаг быстрого выявления и устранения проблем, в частности, «задизайнивания». Это когда вместо упрощения реализации сценариев в погоне за эстетикой процесс решения задач усложняется. Результат — потеря эффективности. Это значит, что при тестировании меньшее количество пользователей поймет, как выполнить те или иные задачи. И среднее время решения задач, и количество успешных попыток выполнения сценариев будут не лучшими. С такой проблемой мы столкнулись в проекте «Мой Билайн» — функциональная кнопка, расположенная в соответствии с гайдами справа в углу, клево выглядела, но пользователи ее не замечали. Пришлось перемещать ее в центр экрана. 

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

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

Поэтому мы применяем специальные API-тестеры, которые в автоматическом режиме проверяют корректность работы сервера и соответствие спецификации API.

Анализ безопасности

Разработкой приложения должны заниматься специалисты, знакомые с понятием SA (security assurance).

Тестирование

По мере того, как создается мобильное приложение, мы «облепляем» код модульными тестами (unit test) и постоянно и автоматически подвергаем уже разработанный функционал тестированию. Это позволяет всегда быть уверенными в качестве разработанного кода.

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

1.2 Особенности тестирования мобильных приложений в целом

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

Чтобы понять особенности тестирования мобильных приложений следует принимать во внимание моменты, принципиально отличающие мобильные приложения от десктопных: специфичность ОС для мобильных платформ, различные компании-изготовители устройств и конфигурации комплектующих, функциональность устройств как коммуникаторов и т.п^[4].

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

Тестирование обновлений – частые обновления операционной системы (относительно десктопов) приводят к необходимости обновлять приложение. Обновление должно проходить просто и не требовать от пользователя специфических знаний. Следует так же проверять различные возможные пути установки приложения (Wi-Fi, 3G, установка с ПК, на SD).

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

Тестирование удобства пользования (usability). Этот вид тестирования является одним из важных, так как в условиях высокой конкуренции юзабилити приложения входит в список основных параметров, влияющих на популярность продукта. Позволяет выявить части приложения, которые недостаточно привлекательны или вызывают затруднения в навигации или использовании на сенсорных экранах. Следует так же убедиться, что модель потребления ресурсов приложением соответствует целевой аудитории. Например, приложения-напоминания не должны вызывать чрезмерное потребление энергии. Зачастую это тестирование проводится в виде бета-тестирования.

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

Случайное тестирование (fuzzy testing, “monkey” testing) – приложение должно корректно реагировать на возникновение случайных и непредсказуемых событий. Мобильные устройства чаще других попадают в условия, в которых получают хаотичную бесполезную информацию (например, незаблокированный девайс в кармане), потому приложение должно адекватно реагировать на подобные потоки данных.

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

Лабораторное тестирование – имитация реальных условий качества связи и окружающей среды. Обычно неочевидно, как поведёт себя приложение, например, при нестабильном сигнале Wi-Fi или с нулевым балансом на счету в сети 3G. Данный вид тестирования позволяет проверить подобные случаи.

Аттестационное тестирование используется для подтверждения соответствия приложения стандартам, лицензионным соглашениям и условиям использования:

Android

• Установочный файл приложения (.apk) должен быть согласован с Program Policies .
• В случае публикации обновлённой сборки желательно придерживаться порядка управления версиями (например, принятого порядка нумерации версий).
• Приложение не должно противоречить документу UIG .

Так же для отдельных магазинов приложений (Amazon App Store, Samsung Apps, Yandex.Store и подобных) могут существовать свои собственные требования и гайдлайны.

iPhone

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

Windows Phone 7-8

Приложение должно соответствовать всем категориям app certification requirements.

Перечень моментов, которые должны быть протестированы

Размер экрана и touch-интерфейс:

• Все элементы должны быть такого размера, чтобы пользователь мог однозначно попасть по ним.
• Отсутствие пустых экранов в приложении – пользователь не должен оказываться в ситуации, в которой не очевидно, что сейчас происходит и что делать.
• Следует проверять многократное быстрое нажатие на кнопку – часто при этом может случиться падение приложения. Так же следует проверять мультитач – нажатие на несколько кнопок одновременно.
• Следует проверять наличие или отсутствие «нативных» жестов (pinch-to-zoom, doubletap) – если, например, поддерживается зум части приложения, то должен использоваться жест по умолчанию. А если нет необходимости выделять картинку, то по даблтапу она не должна выделяться.

Ресурсы устройства:

• Утечки памяти. Особенно может проявляться на окнах, с большим количеством информации (длинные списки как пример), во время задач с длительным workflow (когда пользователь долго не выходит из приложения), при некорректно работающем кэшировании изображений.
• Обработка ситуаций нехватки памяти для функционирования ОС, когда приложение активно или работает в фоне.
• Недостаток места для установки или работы приложения.
• Отсутствие в некоторых устройствах поддерживаемых приложением функций (3G, SD-карта и т. п.).
• Установка или перенос приложения на карту SD.

Различные разрешения экрана и версии ОС:

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

Реакция приложения на внешние прерывания

• Входящие и исходящие SMS, MMS, звонки, оповещения других приложений.
• Выключение устройства, изъятие аккумулятора, разрядка устройства.
• Переход в режим ожидания (в том числе и с защитой паролем). Смена ориентации устройства в режиме ожидания.
• Отключение и подключение провода.
• Отключение и включение сети, Bluetooth, авиарежима, GPS.
• Потеря связи с сервером или прокси (подключение есть, но пакеты не доходят).
• Отключение и подключение SD-карты, дополнительных устройств вроде физической клавиатуры или гарнитуры.
• Зарядка устройства.
• Работа с акселерометром.
• Работа с физической клавиатурой (если в списке поддерживаемых моделей есть такие).

Платный контент внутри приложения:

• Соответствие цены и содержимого, заявленного в приложении, тому, что попадает к пользователю.
• Восстановление покупки (обновление приложения).

Интернационализация (проверять и в портретном, и в ландшафтном режиме!):

• Проверка корректности перевода.
• Проверка того, что все надписи входят в соответствующие формы, кнопки и т.п.
• Проверка форматов дат, разделителей в числах, специфических особенностей локализации (вроде пробела перед знаком вопроса во французской, верхних индексов “o” и “a” в порядковых числительных в испанской и других нетривиальных моментов).

Постоянная обратная связь с пользователем:

• У всех нажимаемых элементов должно быть нажатое состояние (отклик на действие) – благодаря этому пользователь всегда будет видеть, действительно ли нажатие случилось. В Android-приложениях у элементов может быть ещё одно состояние – focused.
• Реакция кнопок на нажатие. Скорость отклика элементов должна быть достаточно высокой. Желательно использовать для проверки этого пункта самые слабые устройства среди поддерживаемых.
• Сообщения при загрузке контента или прогресс-бар.
• Сообщения при ошибке доступа к сети, BT, GPS.
• Наличие понятных сообщений при попытке удалить важную информацию.
• Наличие экрана или сообщения при окончании процесса или игры.
• Наличие и синхронность звуков или вибрации с уведомлениями и другими событиями на экране.

Обновления:

• Убедиться, что поддерживаются те же версии ОС, что и предыдущая версия (если новая версия приложения использует новые возможности ОС, то для старых поддерживаемых версий ОС необходимо создание урезанной версии приложения).
• Проверка адекватного обновления (сохраняются все данные пользователя и т. п.).

Аттестационное тестирование.

Различные версии ОС могут использовать отличные соглашения и правила (интерпретация жестов, правила навигации). Следует учитывать это при поддержке приложением нескольких версий ОС.

1.3 Проблемы, с которыми сталкивается тестировщик мобильного приложения

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

Мобильные устройства работают от аккумуляторов, и потому вынуждены автоматически переходить в режим ожидания спустя пару минут бездействия. Это значит, что вам придётся включать телефон перед каждым тестированием, что при одновременном тестировании нескольких телефонов, занимает приличное количество времени. Конечно, на многих устройствах можно отключить автоматическую блокировку (или хотя бы сделать время отключения довольно большим), но желательно всё же работать с самыми распространёнными среди пользователей настройками ОС^[5].

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

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

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

Для тестирования GPS придётся вооружиться дополнительным инструментарием от энтузиастов и надеяться, что он работает достаточно похоже на реальные условия.

Для проверки слабого или отсутствующего Wi-Fi и 3G-сигнала обычно приходится либо сооружать лабораторию, либо использовать различные хитрости вроде коробочек из фольги.

Создание скриншотов и видео на мобильных устройствах так же зачастую нетривиальная работа, особенно если тестируется телефон, отключенный от компьютера по условиям теста или по каким-то иным причинам. Например, встроенная возможность снятия скриншота экрана на Android-устройствах появилась сравнительно недавно – с четвёртой версии. А про бесплатный способ снимать видеопоток с экрана Apple-устройства без jailbreak вообще мало кто может сказать что-то вразумительное.

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

Если Вам понравилась наша статья – расскажите о ней друзьям. Также Вы можете почитать наш обзоринструментов для тестирования мобильных приложений.

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

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

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

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

1. Если ваши целевые устройства не относятся к числу "открытых" ("open devices"), то выдвигает ли поставщик устройств какие-либо требования, которые должны быть обязательно удовлетворены?
2. Существуют ли дополнительные компоненты, которые также должны быть развернуты для того, чтобы приложение могло нормально функционировать на всех типах устройств, выбранных в качестве целевых?
3. Каким образом конечный пользователь будет устанавливать ваше приложение?

С ростом числа мобильных платформ разработка стандартизированных межплатформенных приложений становится все более привлекательным направлением. HTML5^[6] предлагает новые возможности, позволяющие создавать полноценные приложения для мобильных устройств с поддержкой работы в автономном режиме. Узнайте, как создавать Web-приложения с поддержкой автономной работы, используя инструменты Open Source и приемы, знакомые каждому Web-разработчику.

HTML5 – это общий термин для целого ряда развивающихся Web-технологий, включая стандартизированные технологии работы с насыщенным мультимедийным контентом и интерактивность. HTML5 также может служить основой для разработки приложений, обеспечивающих надежную работу в автономном режиме. Для опытных Web-разработчиков использование HTML5 является более привлекательным по сравнению с изучением новых транслируемых языков, таких как Objective-C или Java™, однако для разработки HTML5-приложений также необходимо иметь определенный уровень знаний. Из этой статьи вы узнаете, как реализовать в вашем приложении работу с онлайновым содержимым и в то же время предоставить возможность работы пользователям, не подключенным к сети.

Глава 2 Создание мобильного приложения с Nokia Qt SDK

Для начала необходимо установить Nokia Qt SDK^[7]. Инсталлятор установит и настроит необходимый набор инструментов для разработки мобильных приложений.

Создадим проект с активным режимом Справка чтобы мы могли следовать этим инструкциям во время работы.

1. Выберите Файл > Новый файл или проект... > Проект Qt C++ > Мобильное приложение Qt > Выбрать....

Откроется диалог Введение и размещение проекта.

1. В поле Имя введем BatteryIndicator.
2. В поле Создать ввести путь к файлам проекта. Например, C:\Qt\examples, и нажмите Вперёд.

Откроется диалог Выбор требуемых профилей Qt.

1. Выбрать цели Maemo, Эмулятор Qt и Устройство Symbian и нажмите Далее.

Данные цели будут присутствовать в списке если вы установили соответствующие среды разработки, например, в составе Nokia Qt SDK.

Откроется диалог Информация о классе.

1. В поле Имя класса вводим BatteryIndicator в качестве имени класса.
2. В списке Базовый класс выбрать QDialog в качестве типа базового класса.

Поля Заголовочный файл, Файл исходников и Файл формы будут обновлены автоматически в соответствии с выбранным вами именем класса.

1. Нажать Вперёд.

Откроется диалог Управление проектом.

1. Проверить настройки проекта и нажмите Завершить для создания проекта.

Проект BatteryIndicator будет содержать следующие файлы:

• batteryindicator.h
• batteryindicator.cpp
• main.cpp
• batteryindicator.ui
• BatteryIndicator.pro

Файлы содержат необходимые строки кода которые вы должны будете изменить как описано в следующих разделах. Вам не требуется изменять файл main.cpp.

Описание мобильного API Qt

Мастер Новый автоматически добавит требуемую при использовании мобильного API Qt или разработки приложений для устройств Symbian информацию в файл .pro. Вы должны изменить эту информацию для описания используемого вами мобильного API Qt.

Этот пример использует System Info API, поэтому вы должны описать его как продемонстрировано в в следующем фрагменте кода:

CONFIG += mobility

MOBILITY = systeminfo

Каждый мобильный API имеет своё значение которое вам необходимо добавить в качестве значения MOBILITY для использования этого API. Чтобы посмотреть список API и соответствующих значений которые вы можете присвоить MOBILITY, смотрите Пример Quickstart.

Следующий фрагмент кода демонстрирует необходимую информацию для разработки под Symbian. Qt Creator генерирует UID для тестирования приложения на устройстве. От вас требуется только изменить UID и возможности если вы хотите сделать приложение доступным для всех и получить подпись Symbian Signed.

symbian {

TARGET.UID3 = 0xecbd72d7

# TARGET.CAPABILITY +=

TARGET.EPOCSTACKSIZE = 0x14000

TARGET.EPOCHEAPSIZE = 0x020000 0x800000

}

Проектирование пользовательского интерфейса

1. В режиме Редактор дважды нажмите на файле batteryindicator.ui в виде Проекты для запуска интегрированного Qt Designer.
2. Перетащите виджет Progress Bar (QProgressBar) на форму.

1. В панели Свойства измените значение свойства  objectName на batteryLevelBar.

Завершение заголовочного файла

Файл batteryindicator.h содержит некоторые необходимые директивы #include, конструктор, деструктор и объект Ui. Вы должны включить заголовочный файл System Info, добавить ссылку на мобильное пространство имён и добавить закрытую функцию для обновления значения уровня батареи в индикаторе при его изменении.

1. В режиме Проекты нажмите два раза на файле batteryindicator.h чтобы открыть его для редактирования.
2. Включите заголовочный файл System Info как продемонстрировано в следующем фрагменте кода:

#include <QSystemInfo>

1. Добавьте ссылку на мобильное пространство имён как продемонстрировано в следующем фрагменте кода:

QTM_USE_NAMESPACE

1. Опишите закрытую функцию в секции private за Ui::BatteryIndicator как продемонстрировано в следующем фрагменте кода:
2. private:
3. Ui::BatteryIndicator *ui;
4. void setupGeneral();
5. QSystemDeviceInfo *deviceInfo;

Завершение файла исходных кодов

Теперь заголовочный файл завершён, перейдём к файлу исходных кодов batteryindicator.cpp.

1. В режиме Проекты нажмите два раза на файле batteryindicator.cpp чтобы открыть его для редактирования.
2. Создайте объект QSystemDeviceInfo и установите его значение. Затем соедините сигнал который отражает изменение уровня батареи со слотом setValue индикатора выполнения. Это продемонстрировано в следующем фрагменте кода:
3. void BatteryIndicator::setupGeneral()
4. {
5. deviceInfo = new QSystemDeviceInfo(this);
6. ui->batteryLevelBar->setValue(deviceInfo->batteryLevel());
7. connect(deviceInfo, SIGNAL(batteryLevelChanged(int)),
8. ui->batteryLevelBar, SLOT(setValue(int)));

}

1. Используйте конструктор для установки начальных значений и проверки того, что созданный объект находится в определённом состоянии, как продемонстрировано в следующем фрагменте кода: 
2. BatteryIndicator::BatteryIndicator(QWidget *parent) :
3. QDialog(parent),
4. ui(new Ui::BatteryIndicator),
5. deviceInfo(NULL)
6. {
7. ui->setupUi(this);
8. setupGeneral();

}

Сборка и запуск вашего приложения

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

В эмуляторе Qt запустите пример скрипта runOutOfBattery.qs чтобы посмотреть как будет меняться значение в приложении Battery Indicator. Выберите Scripting > examples > runOutOfBattery.qs > Run.

Тестирование на устройстве Symbian

Вам также необходимо проверить приложение на реальных устройствах. Прежде чем вы начнёте тестирование на устройствах Symbian, вы должны подключить их к компьютеру и установить на них необходимое программное обеспечение.

1. Установите на устройстве библиотеки Qt 4.6.2, мобильные библиотеки Qt, и приложение отладки TRK. Для получения дополнительной информации смотрите Настройка окружения разработки для Symbian.
2. Запустите TRK на устройстве.
3. Нажмите Выбор цели и выберите Устройство Symbian.
4. Нажмите Выполнить для сборки приложения для устройства Symbian.

Тестирование в эмуляторе Maemo

Эмулятор Maemo эмулирует окружение устройства Nokia N900. Вы можете проверить приложение в условиях, которые практически идентичны устройству Nokia N900 с версией программного обеспечения 1.2 (V10.2010.19-1).

Для получения дополнительной информации смотрите Использование эмулятора Maemo.

Заключение

С каждым днем на рынке появляется все больше мобильных устройств. Хотя приложения можно разрабатывать отдельно для каждой вновь появляющейся платформы и аппаратной конфигурации, для небольших динамичных групп разработчиков более предпочтительна возможность создавать межплатформенные мобильные Web-приложения с сопоставимыми рабочими характеристиками. Для разработчиков, знакомых с HTML, JavaScript и CSS, мобильные Web-приложения привлекательны тем, что могут создаваться как прототипы более серьезных специализированных приложений, а также как самостоятельные первоклассные системы.

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

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

Список использованной литературы

1) Информатика / под ред. проф. Ю. А. Романовой - М.: Эксмо, 2005; 322 с.

2) Молчанов, А. Ю. Системное программное обеспечение / А. Ю. Молчанов.; СПб.: Питер, 2003; 400 с.

3) Основы алгоритмизации и программирования. Практикум. Игорь Семакин, Александр Шестаков.Год: 2013. Издательство: Academia. Страниц: 144

4) Острейковский, В. А. Информатика / В. А. Острейковский - М.: Высшая школа, 2001; 319 с.

5) http://itech-mobile.ru/stages.html

6) http://www.creabox.ru/services/programs/pp_mobile/

7) http://www.enterra.ru/blog/mobile_qa/

8) http://studopedia.ru/3_75944_etapi-razrabotki-prilozheniy.html

9) http://www.intuit.ru/studies/courses/2335/635/lecture/13780

1. http://www.intuit.ru/studies/courses/2335/635/lecture/13780 ↑

2. http://itech-mobile.ru/stages.html ↑

3. http://studopedia.ru/3_75944_etapi-razrabotki-prilozheniy.html ↑

4. Информатика / под ред. проф. Ю. А. Романовой. &#8213; М.: Эксмо, 2005; 322 с. – С. 68. ↑

5. Основы алгоритмизации и программирования. Практикум. Игорь Семакин, Александр Шестаков.2013г. Издательство: Academia.:- С. 23. ↑

6. Основы алгоритмизации и программирования. Практикум. Игорь Семакин, Александр Шестаков.2013г. Издательство: Academia. – с. 44 ↑

7. http://www.enterra.ru/blog/mobile_qa/ ↑