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

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

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

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

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

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

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

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

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

Перед тем, как представить своё мобильное приложение миру, нужно позаботится о двух вещах: надёжном API-сервере и соблюдении правил Google Play Store и Apple App Store.

---

Рисунок 3. Внедрение на рынок

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

Публикация приложения в Google Play Store и Apple App Store – трудоёмкий процесс. Придётся убедиться в том, что приложение отвечает требованиям магазина, заполнить несколько форм для каждого из них, подготовить скриншоты и маркетинговые материалы, составить текст описания… а Apple ещё и тщательно в течение нескольких дней будет проверять само приложение и даже может не только потребовать изменений, но и отказать в публикации из-за “бессмысленности” приложения. Нет, я не исключаю вероятность того, что магазин примет приложение без лишних вопросов, и через несколько дней оно будет доступно для скачивания. Просто могут возникнуть возможные трудности, которые появятся с вероятностью в 99% [5].

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

Рисунок 4. Мониторинг

Для отслеживания падений приложения есть немало библиотек. Они хранят информацию о том, что делал пользователь во время падения, на каком устройстве оно произошло и многое другое – в общем, всё, что поможет разработчикам решить проблему. Кроме того, функцию отправки сообщения о падении можно встроить в само приложение. Останется только рассортировать их. Могут быть использованы такие инструменты как: Firebase и Bugsee.

Современные системы аналитики мобильных приложений собирают информацию об аудитории приложения (распределение пользователей по полу, возрасту, местонахождению, языку и т.д.) и особенностях взаимодействия с ним (времени входа в приложение, времени, проведённом в приложении, количестве просмотренных экранов и пр.). Некоторые даже составляют тепловые карты, которые показывают, на какие кнопки пользователи нажимают чаще остальных. Используются эти данные как ориентиры на будущее: вкладывайтесь в доработку тех областей, в которых концентрация действий аудитории наиболее высока. Могут быть использованы такие инструменты как: Firebase, Яндекс.Метрика, Facebook Analytics, Apptentive, Google Analytics и Appsee.

---

Этот показатель нельзя измерить двумя предыдущими способами, но следить за ним необходимо. Как часто происходило то или иное действие и как долго оно длилось – вот вопросы, которые помогут оптимизировать работу приложения. Если простейшее действие занимает больше времени, чем ожидалось, это тревожный сигнал. Может быть использован такой инструмент как: Prometheus.

Оценки и отзывы в магазинах крайне важны, особенно для новых приложений. Всегда отвечайте комментаторам: благодарите за хорошие слова и постарайтесь помочь тем, кто столкнулся с трудностями при использовании вашего приложения. Комментаторы обычно не ожидают, что им ответят реальные разработчики. Чуть больше клиентоориентированности – и две звезды превращаются в пять, а ваша репутация взлетает до небес [8].

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

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

Разработка жизненного цикла мобильного приложения

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

Первый этап проектирования, который предусматривается техническим заданием — это эскизный проект. Он включает в себя создание визуальных отображений: чертежей, графиков, планов и рисунков объекта, которые дают возможность увидеть общую концепцию будущего проекта. Рисование эскизов кажется простым делом, но это лишь на первый взгляд. Довольно сложно конвертировать мысли сразу в рабочее приложение или любой другой готовый продукт. При возникновении проблем на поздних этапах проекта, их исправление требует больших ресурсов, чем правки на начальных этапах. Поэтому важно соблюдать всю поэтапность реализации проекта. Концепция проекта должна четко отражать, как идея будет визуализирована в пользовательском интерфейсе. Как раз для этого и нужны эскизы. Все начинается с идеи, которую нужно перевести в пользовательский интерфейс. Недостаточно просто решить, что есть необходимость в разработке приложения, которое выполняет определенные функции. Необходимо знать, что пользователь увидит на каждом экране приложения, и что ему понадобиться сделать, что бы получить результат от выполнения заданных функций. На этапе создания эскиза возможно наглядно рассмотреть различные замыслы, прежде чем реализовывать итоговый вариант [17]. Перед тем как приступать к созданию макетов, было выполнено эскизирование приложения. Создание эскизов позволяет представить, как будет выглядеть веб-сайт, разработать удобство пользования им, продумать расположение элементов сайта. Эскизы экранов приложения представлены на рисунке 5.

---

Рисунок 5. Эскизы экранов приложения

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

Рисунок 6. Эскизы основной иконки

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

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

Таблица 1. Использование цвета.

Шестнадцатиричный код цвета	Визуальное представление
#6d986a
#bb6a00
#a50000
#efefef

В приложении используется 8 иконок, как для обозначения кнопки и пункта меню, так и для простого информирования пользователя о статусе ингредиента. Созданы графические элементы, представленные ниже на рисунке 7.

Рисунок 7. Графические элементы приложения

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

Рисунок 8. Основная иконка приложения

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

---

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

Рисунок 9. Макет раздела «Пищевые добавки»

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

Рисунок 10. Макет раздела «Ингредиенты в косметике»

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

Рисунок 11. Макет экрана с информацией о компоненте

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

Для реализации данного способа необходимо собранную информацию преобразовать в файлы формата json. JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript и обычно используемый именно с этим языком. В Android есть готовые классы для работы с JSON: JSONObject, JSONArray, JSONWriter, JSONStringer и т. д. Теперь перейдем к работе с анимацией в приложении и навигацией по нему. По задумке переход от одного раздела приложения к другому должен осуществляться с анимацией перелистывания из стороны в сторону по свайпу. Для реализации данного решения необходимо было подключить библиотеку Android Support Package. Использовать эту библиотеку можно для версий Android 1.6 и старше. Конкретно для данной задачи понадобятся классы ViewPager и PagerAdapter. ViewPager использует PagerAdapter, который создает компоненты View и заполняет их переданными данными. Для этого также необходимо наследовать класс от PagerAdapter и реализовать в нем некоторые методы. Добавление и удаление экранов реализуется с помощью методов instantiateItem() и destroyItem() соответственно. View для отображения можно создавать прямо в адаптере. Такой подход хорош тем, что ViewPager можно настраивать так, чтобы в адаптере не хранились все экраны сразу. По умолчанию адаптер хранит текущий экран, и по одному слева и справа от него. Это может сэкономить память, если содержание экранов слишком сложное. Для отображения нижнего меню необходимо подключить библиотеку Android Design Support Library. В ней нам нужен такой компонент, как BottomNavigationView. Это нижняя панель навигации, позволяющая переключаться между экранами приложения в одно касание, она предназначена в основном для смартфонов, поскольку расположение в нижней части экрана обеспечивает удобный и быстрый доступ для пользователя. Компоненту BottomNavigationView присваиваем «слушатель», который определяет нажатие на пункты панели по идентификаторам и прописываем нужные действия в конструкции switch. Слушатель (Listener) — это уведомляемый о некотором событии объект. Чтобы слушатель смог реагировать на определенное со- 45 бытие источника он должен быть им зарегистрирован, т.е. подключен к источнику. Listener должен реализовывать определенные методы для получения и обработки уведомлений о событии.

---