требования к созданию мобильного приложения

Интернет доступ к своему содержимому и функционалу в виде упорядоченного набора взаимосвязанных HTML-страниц

оформление и способы представления информации

2.1 Предмет разработки

Предметом разработки является

Назначение мобильного приложения:

– Вывод рекламной информации о мобильном приложении;

– Осуществление администрирование мобильного приложения;

– Вывод аналитической информации (с возможностью отправить на принтер и на почтовый адрес);

Цель создания мобильного приложения:

– Агрегирование сервисов курортной зоны России в одной месте;

– Возможность бронирования путешествий «в один клик»;

– Обмен сообщениями и отзывами между пользователями;

Целевая аудитория сайта:

– Семейные пары (средний возраст которых родителей 30-35 лет) с маленькими детьми, которые планируют провести отдых на курортных зонах России (Сочи, Крым и тд);

– Молодежь (от 18 до 30 лет), которая планирует отправиться на зимние курортные зоны (Красная поляна, Кавказ и тд.);

– Активные люди, которые любят путешествовать по России и сами планируют свой отпуск;

2.2 Назначение документа

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

Подпись Заказчика и Исполнителя на настоящем документе подтверждает их согласие с нижеследующими фактами и условиями:

3.1 Требования к дизайну сайта

При разработке сайта должны быть использованы преимущественно светлые и контрастные цветовые решения (пример дизайнерских решений: https://habrahabr.ru/post/334722/ ).

Оформление должно быть разработано в достаточно консервативном ключе.

На страницах недолжно быть большого объема текста.

В дизайне сайта не должны присутствовать:

– много сливающегося текста;

– тёмные и агрессивные цветовые сочетания и графические решения.

Рис. Пример формы авторизации

3.2 Порядок утверждения дизайн-концепции

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

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

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

4.1 Классы пользователей

3) Администратор – пользователь, авторизованный в интерфейсе сайта

4.2 Требования к представлению мобильного приложения

Требования к представлению главной страницы мобильного приложения.

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

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

Контентная часть главной странице мобильного приложения должна включать:

Требования к отображению раздела «проживание».

При переходе пользователя на раздел «проживание» пользователю в верхней части экрана

Требования к внутренним страницам раздела проживание.

Требования к отображению раздела «развлечения».

При переходе пользователя на раздел «развлечения» пользователю

Требования к внутренним страницам раздела «развлечения».

Требования к разрабатываемому разделу «транспорт»

Требования к разрабатываемому разделу «питание»

Требования к внутренним страницам раздела «питание».

Требования к внутренним страницам раздела «личный кабинет».

Требования к странице «оплата».

Оплата путевки, тура, экскурсии, снаряжения и тд.

Оплата авиа, жд билетов.

Требования к структуре сайта

Пользователи группы «Администратор-владелец» могут редактировать все поля. Пользователи группы «Администратор-аналитик» могут выгружать информацию, но не могут редактировать и просматривать информацию о клиентах.

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

Данные для доступа (авторизации):

Ниже формы располагаются ссылка:

Форма «Забыли пароль» содержит поля:

При неудачной попытке авторизации – появляется приглашение для повторной попытки

авторизоваться с формой авторизации.

Списки рассылок и уведомления

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

просматривать полученные уведомления.

4.4 Требования к разделению доступа

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

Комментарии к статьям и разделам могут оставлять только зарегистрированные пользователи.

5.1 Требования к информационному обеспечению

Требования к хранению данных

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

СУБД. Исключения составляют файлы данных, предназначенные для просмотра и скачивания

(изображения, видео, документы и т.п.). Такие файлы сохраняются в файловой системе, а в БД

размещаются ссылки на них.

Наполнение различных сайтов, функционирование которых поддерживается одной и той же

инсталляцией системы, должно храниться под управлением единой СУБД.

Требования к языкам программирования

Для реализации статических страниц и шаблонов должны использоваться языки HTML 4.0 и CSS.

Исходный код должен разрабатываться в соответствии со стандартами W3C (HTML 4.0).

Для реализации интерактивных элементов клиентской части должны использоваться языки

JavaScript и DHTML.

Для реализации динамических страниц должен использоваться язык PHP.

Для разработки мобильного приложения должен быть использован ReactJS

Требования к организации гиперссылок

Все ссылки в мобильном приложении должны быть относительными (за исключением внешних).

Требования к иллюстрациям

Все рисунки и фото объемом более 1 kb (кроме элементов дизайна страницы) должны быть

выполнены с замещающим текстом. Все рисунки должны быть в формате gif или jpg.

Требования к объему одной страницы

Объем одной стандартной загружаемой страницы сайта в среднем не должен превышать 170 kb.

5.2 Требования к программному обеспечению

Желательно, чтобы PHP не был запущен в SafeMode.

5.3 Требования к техническому обеспечению

Точные технически характеристики сервера будут уточнены после завершения системы и

обширного тестирования всех модулей

5.4 Требования к лингвистическому обеспечению

Сайт должен выполняться на русском языке.

5.5 Требования к эргономике и технической эстетике

Дизайн приложения должен быть адаптивный и работать корректно во всех устройствах (Android и IOS) с разрешением экрана 720х1280 пикселей, 1080х1920, 2560×1440, 640х1136 и 750х1334 пикселей соответственно. Интерфейс подключаемых модулей должен быть выполнен в едином стиле с интерфейсом ядра системы и должен обеспечивать возможность прозрачного перемещения администратора между модулями системы и использование одинаковых процедур управления и навигационных элементов для выполнения однотипных операций.

6.1 Требования к наполнению информацией

Общие требования к информационному наполнению

Наполнение страниц мобильного приложения должно происходить в автоматическом режиме.

6.3 Требования к персоналу

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

Администратор, оператор: уверенный пользователь сети Интернет, знание Microsoft Word.

Прочие пользователи: уверенный пользователь сети Интернет.

6.4 Порядок предоставления дистрибутива

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

– архив с исходными кодами всех программных модулей и разделов сайта;

– дамп проектной базы данных с актуальной информацией.

Дистрибутив предоставляется на CD-диске в виде файлового архива.

6.5 Порядок переноса сайта на технические средства заказчика

После завершения сдачи-приемки сайта, в рамках гарантийной поддержки Исполнителем

Перед осуществлением переноса Заказчик обеспечивает удаленный shell-доступ к веб-серверу и

доступ к базе данных сайта.

6.6 Дополнительные требования

Требования к производительности

Работа любого скрипта не должна превышать 60 секунд.

При условии нагрузки на сервер не более

500.000 обращений к страницам портала в сутки.

Требования к безопасности

Требуется защитить исходный код общей части сайта. Не должно быть возможности считать php-

код скриптов. Требуется разграничение доступа.

Пароли пользователей хранятся в зашифрованном виде. Перехват данных на уровне протокола tcp возможен.

На уровне СУБД должно быть реализовано разграничение доступа к данным в БД.

Требования к надежности

Система может быть недоступна не более чем 24 часа в год. Резервирование данных осуществляет

хостинг-провайдер. У администратора сайта должна быть возможность выгрузить и загрузить

Источник

Разработка успешного Android-приложения: принципы, требования

Одна из целей настоящей статьи — объяснить преимущества разработки родных приложений на языке Java для платформы Android над другими способами доставки контента на мобильных устройствах.

Требования к приложениям для мобильных телефонов

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

Проектирование приложений для платформы Android

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

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

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

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

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

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

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

Приложение будет придерживаться стандартов стиля и дизайна Android, где это возможно, чтобы оно соответствовало другим приложениям Android на устройстве.

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

Следует учесть ряд важных характеристик устройства, описанных в следующих подразделах.

Размер и разрешение экрана. Чтобы классифицировать устройства по типу эк­рана, платформа Android определяет две характеристики для каждого устройства: размер экрана (физические размеры экрана) и разрешение экрана (физическая плот­ность пикселей на экране, или dpi (количество точек на дюйм)). Чтобы упростить все типы конфигураций экрана, система Android обобщает их на группы, которые упрощают их настройку.

При разработке приложения проектировщик должен определить подходящие размер и разрешение экрана.

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

Конфигурации ввода. Многие устройства предоставляют различные типы поль­зовательских механизмов ввода, такие как аппаратная клавиатура, трекбол или пятипозиционная навигационная панель. Если вашему приложению требуется опреде­ленный вид аппаратного обеспечения для ввода данных, необходимо объявить его в файле AndroidManifest.xml и помнить, что на сайте Google Play Store ваше при­ложение не будет отображаться на устройствах, которым не хватает этой функции. Однако для приложения редко требуется определенная конфигурация ввода.

Особенности устройства. Существует множество аппаратных и программных функций, которые могут или не могут существовать на данном устройстве на базе Android, таком как камера, датчик освещенности, механизм Bluetooth, определенная версия OpenGL или качество сенсорного экрана. Вы никогда не должны предпола­гать, что определенная функция доступна на всех устройствах на базе Android (кро­ме доступности стандартной библиотеки Android).

Усовершенствованное приложение для Android будет использовать два типа меню, предоставляемые платформой Android, в зависимости от обстоятельств.

Команды в контекстном меню, которые появляются при длительном нажатии на элемент, должны дублироваться в активности, которая запускается при обычном на­жатии на этот элемент.

Итак, сформулируем самые общие правила.

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

В нашем приложении для платформы Android будет широко использоваться ме­ханизм намерений ( Intent ), разработанный компанией Google для передачи данных между объектами класса Activity. Намерения не только используются для передачи данных между представлениями в одном приложении, но также позволяют переда­вать данные или запросы внешним модулям. Таким образом, большое количество функций может быть адаптировано приложением Android с помощью встроенных функций из других приложений, вызываемых вызовами намерений. Это упрощает процесс разработки и обеспечивает общий внешний вид и функциональность во всех приложениях.

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

Как правило, данные предоставляются в таких форматах, как XML, SOAP, или в виде какого-либо другого представления, связанного с XML. Форматы наподобие SOAP являются тяжеловесными, и поэтому передача данных с вспомогательных сер­веров в этом формате значительно увеличивает время разработки, поскольку ответс­твенность за преобразование этих данных во что-то более управляемое возлагается на приложение или на объект, находящийся на сервере промежуточного програм­много обеспечения.

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

Источник

Разработка мобильных приложений: с чего начать

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

Тенденции

Чем пользуются владельцы мобильных телефонов?

Статистика

За 2012 год в РФ продано порядка 12,6 миллионов смартфонов: Россия считается одной из быстроразвивающихся в этом плане стран.

Если взглянуть на такой же график по всему миру, то увидим, что и тут Android в авангарде с ¾ рынка.

За второй квартал 2012 года по всему миру было продано 104 миллиона телефонов Android — как население довольно крупной страны. Но нас как мобильных разработчиков интересует не только наличие смартфона, но и то, как с ним работают. Существенная доля обладателей устройств на Android пользуется ими как обычными телефонами: SMS, звонки — и все. Они не активируют устройство в Google Play, не скачивают приложения.

Не все люди обзавелись телефонами в 2012 году, поэтому реальное распределение сил среди мобильных операционных систем демонстрирует наша внутренняя статистика. В эту статистику входят Россия и страны СНГ: Украина, Белоруссия, Казахстан, Узбекистан.

Установка приложений

При выборе платформы, под которую будет разрабатываться приложение, важно знать статистику по уже существующим приложениям. Графики исследовательской компании App Annie от сентября 2012 года показывают, как растут два конкурирующих магазина Apple и Google.

По количеству скачиваний на первом месте Google Play: больше устройств, больше скачиваний, больше трафика и рост при этом +66% по сравнению с январем 2012 года. Рост iOS оказался в два раза меньше, порядка 30%. Но главный график – какую выручку приносят пользователи. И здесь ситуация в корне иная. Проще зарабатывать на iOS, но деньги есть и в Google Play, если уметь их забирать.

Типы мобильных приложений

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

Мобильные сайты, веб-приложения

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

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

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

Статистика

Приведу статистику скачиваний на примере наших мессенджеров.

Во-первых, у нас есть приложение ICQ, которое постоянно развивается: среди последних изменений стоит отметить аудиозвонки. Второй мессенджер Mail.Ru Group – Агент. В Агенте реализован примерно тот же функционал, и, хотя у него была немного другая история развития, мы выпускаем версии практически под все платформы и его можно найти в любом сторе.

Основная разница между двумя этими приложениями – это их аудитория. ICQ – это международный продукт. Программа скачивается не только в России, им активно пользуются жители Европы, Латинской Америки. Агент же изначально делался в России и для русскоязычных пользователей.

Тем интереснее сравнить статистику скачиваний из магазинов.

Большая часть 62% иностранной аудитории идет в Google Play. Примерно 1/5 идет в AppStore, 14% — в Ovi Store. И уже оставшиеся 5% делят магазины для платформ Windows Phone (4%) и Samsung Bada (1%). С Агентом ситуация в корне другая: доли Google Play и Ovi примерно одинаковые. Ну а 10% AppStore наглядно демонстрируют любовь к «яблочной» продукции в нашей стране.

Процесс создания мобильного приложения

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

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

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

Проектирование и дизайн

После составления User Story начинается проектирование и разработка дизайна.

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

При разработке дизайна обязательно используются гайдлайны.

Гайдлайн в общем понимании – это документ, который выпускает компания, и по которому дизайнеры и разработчики понимают принцип построения взаимодействия приложения с пользователем. Условно говоря, для iOS кнопки надо делать круглыми, а для Windows Phone – квадратными. Однако мы используем и внутренние гайдлайны для разработчиков. Таким образом результат работы дизайнера чаще всего состоит из макетов, гайдлайнов и нарезки графики.

Макеты лучше всего подавать «перелинкованными», например с помощью ProtoTypr, чтобы была понятна логика переходов. Гайдлайны содержат в себе информацию об отступах, размерах, визуальных эффектах, механике анимации и пр. Этот этап можно пропустить, если в вашем проекте один дизайнер и один разработчик, сидящие рядом друг с другом. Третья часть результата — нарезка графики — должна содержать минимум необходимых графических ресурсов (заботимся о весе приложения), иметь версии для разных разрешений экранов. Чаще всего мы рисуем для ретины и xhdpi-экранов. Далее идет подготовка для неретины и mdpi автоматизированными средствами (если допустимо их использование). Чаще всего руками приходится готовить hdpi-ресурсы.

Передача в разработку. Обсуждение и необходимые правки описания

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

Существует немалое количество способов протестировать приложение.
В мобильной разработке тестировщик – это человек, вокруг которого одни телефоны. У нас есть огромный шкаф, в котором лежат как старые телефоны, так и самые свежие новинки. Внутри мы стараемся тестировать по тест-кейсам. Если внедряется новая фича, по ее описанию составляется тест-план.
Существуют сервисы, помогающие в тестировании. Мы используем HockeyApp – приложение, позволяющее раздавать наш продукт бета-тестерам. Мы пишем в социальных сетях: «Ребята, у нас новое крутое приложение. Кто хочет попробовать?» Желающие получают билд, пользуются приложением, а сервис собирает статистику, составляет креш-репорт и отправляет все это нам.
Также есть сервисы, позволяющие протестировать приложение на разных операционных системах — например, все Android-прошивки версии 2.1 или 2.3. Вы отдаете приложение, сервис скриншотит весь путь, который вы задали, присылает картинки вам на почту, и вы проверяете, все ли в порядке.

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

Важно понимать, что люди более склонны оставлять негативные комментарии. Если у человека все хорошо, он чаще всего просто пользуется приложением, не комментируя. При стабильной работе наших приложений мы получаем 40-50 комментариев ежедневно. В день ошибки количество записей может доходить до 400 на одной платформе. Поэтому имейте в виду, что комментарии – это не полная оценка вашей работы, скорее еще один баг-трекер.

Изменить ситуацию может довольно распространенных «хак» — окно Rate Us. С предложением оставить положительный комментарий в сторе, а в случае проблем написать разработчику. Эффект достаточно сильный, главное — правильно продумать алгоритм показывания диалога юзеру.

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

Еще один интересный мониторинговый сервис – Flurry. Он помогает собирать клиентскую статистику. Flurry предоставляет отчет о том, что делает пользователь в вашем приложении: сколько раз он нажал на кнопку, сколько раз возвращался в приложение и более общие параметры — аудитория, география, пол, возраст и пр.

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

Несмотря на большое количество сторонних сервисов, у нас есть собственная статистика. Какими бы хорошими не были внешние источники, их нужно проверять. Мы способны сами оценивать статистику, но для этого необходимо строить инфраструктуру для генерации отчетов, еженедельной отправки отчетов по email и других вещей, упрощающих жизнь. Поэтому нам проще использовать такие сервисы, как Flurry и Distimo, а к внутренним логам обращаться при возникновении вопросов. Наша практика показывает, что такой подход оправдан: периодически наши данные и данные сервисов несколько разнятся. Если вы склонны проверять статистику, используйте разные источники.

Специфика

Заключение

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

Источник

• ← требования к разработчику мобильных приложений
• требования к транспортным средствам находящимся в эксплуатации приложение 8 →