как разрабатывать приложения для мобильных платформ
Создаем приложение для ANDROID быстро и просто
После успешной установки мы можем создать свой первый проект.
Мы можем его запустить в эмуляторе, который идет комплекте с Visual Studio нажав клавишу F5.
Приводим код к такому виду. Здесь мы создаем WebView контейнер который будет грузить локальный HTML файл, который находится в проекте в папке Assets.
По такому принципу можно создать приложение быстро и просто. Файлы html будут выглядеть одинаково на всех устройствах. То есть, Вы можете сделать приложения для Android и iOS с одинаковым интерфейсом. Не надо изучать сложные языки разметки, не надо изучать сложные макеты (сториборды) на iOS. Все можно сделать на HTML.
В идеале, вместо локальных файлов можно сделать загрузку со стороннего сайта. В этом случае Вы можете менять контент приложения без его обновления в AppStore и Google Play.
Q: Но как быть с функциями самой платформы? Пуш сообщения? Как взаимодействовать с самой платформой?
Все очень просто! JavaScript можно использовать для вызова функций Android:
Мы видим, что теперь программа ругается на Export так как не знает что это такое.
Так вы можете подключать библиотеки если вдруг Visual Studio ругается на что то.
Данная функция это показ всплывающей информации на экране. Она выполняется именно на платформе Андроида. То есть мы можем написать в HTML файле вызов функции Андроида. Получается полное дружелюбие двух платформ по JavaScript интерфейсу. Данные можно передавать туда сюда. Вызывать переход от одной активити в другую. Все через HTML + JavaScript.
Немного модифицируем файл login.htm:
Теперь при нажатии на кнопку HTML вызывается функция Toast андроида и выводиться сообщение пользователю.
На чем собрать мобильное приложение без кода — топ-3 конструктора с примерами приложений
Самый популярный вопрос среди начинающих зерокодеров — можно ли собрать мобильное приложение без программирования. Расскажем, с помощью каких инструментов это можно сделать, чем они отличаются и сколько это стоит.
Существует три подхода к созданию мобильных приложений:
Инструменты зерокодинга уже могут покрыть большинство задач бизнеса. И вместо того, чтобы изобретать велосипед, можно за несколько дней запустить MVP или проверить гипотезу с минимальными затратами. А если в запасе хотя бы пара недель — то и запилить полноценное приложение. Решения на зерокодинге можно собирать в одиночку — вся инфраструктура предоставляется платформами и не надо дополнительно тратиться на хостинг, администрирование серверов и т.п.
При этом обычная разработка затянется на 3−6 месяцев и съест до миллиона рублей — если работать с фрилансером или скромной региональной студией.
Чтобы быть в курсе новостей зерокодинга, присоединяйтесь к телеграм-каналу «Зерокодер» и чату «Я — зекрокодер».
Самые мощные и популярные инструменты мобильной разработки без кода — Adalo, Glide и Bubble. С их помощью можно создать и опубликовать мобильное приложение. Они бывают трех типов:
Мобильная версия сайта — сайт в интернете, адаптированный под экраны смартфонов. Это самый «бесправный» тип приложений: всегда нужен интернет, пуши можно включать только в браузере, постоянно на виду элементы навигации браузера.
PWA (Progressive Web Application) — когда мобильная версия сайта устанавливается на смартфон как приложение. Из плюсов — не надо поддерживать две кодовые базы, под iOS и Android, приложение всегда «обновлено» до последней версии, можно работать с некоторыми нативными функциями смартфонов. Например, отправлять пуши, устанавливать ярлык на экран, элементы навигации браузера не мешают (их просто нет). такие приложения умеют создавать и Bubble, и Adalo, и Glide.
Нативные — когда приложение публикуется в официальных сторах. В Adalo уже встроена такая функция, а приложения на Bubble можно обернуть в специальный контейнер и тоже опубликовать в Google Play и App Store. Нативные приложения позволяют работать со всеми функциями телефона: камерой, микрофоном, GPS, контактами, файлами, акселерометром, push-уведомлениями, памятью девайса, адаптивной версткой — всё, как в обычном коде, только без кода.
Glide — платформа для создания мобильных приложений без кода. Лучше всего функции сервиса описывает девиз «Создавайте приложения из Google Sheet за пять минут, бесплатно». Glide-приложения нельзя загрузить в сторы, но можно опубликовать в интернете как PWA. Платформа отлично подходит для создания простых приложений и MVP — много готовых симпатичных шаблонов, понятные интуитивные настройки.
Adalo — nocode-платформа для создания веб- и мобильных приложений, которые можно публиковать в App Store, Google Play или в интернете как PWA. Новая версия раскатывается в сторы прямо из личного кабинета на платформе, публикуется тоже оттуда (но нужен аккаунт в AppStore и Google Play). Adalo позволяет создавать приложения в интуитивно-понятном интерфейсе методом drag’n’drop из готовых или кастомных дизайн-шаблонов. Эта платформа мощнее Glide и на ней можно собирать более сложные приложения.
Bubble — одна из самых продвинутых визуальных сред программирования для создания веб-приложений. На нем можно собирать настольные или адаптивные веб-приложения для любого размера экрана.
Bubble позволяет проектировать сложную бизнес-логику — это настоящий комбайн. Приложения на Bubble нельзя выкладывать в сторы напрямую, но есть обходные пути — обернуть их в специальный контейнер и после этого опубликовать в маркетплейсах от Apple и Google.
Разработка приложения «под ключ» — сложный процесс, в котором участвует целая команда специалистов. Программисты пишут бэкенд и фронтенд, дизайнеры создают «человеческий» UX/UI и вкусную картинку, тестировщики ищут ошибки, проджекты управляют всем процессом, лиды — командами, эккаунты общаются с клиентами. И каждый не просто просиживает штаны, а действительно работает и нужен.
Сколько денег возьмет за разработку веб-студия и сколько времени потратит, зависит от сложности проекта и имиджа компании, но в среднем — от 500 тыс. до 5 млн рублей, а средний срок разработки — 4−6 месяцев (по сведениям с Хабра, DTF и Appinventive). Сложные приложения легко могут стоить дороже 10 млн рублей и пилиться больше года — особенно если поджимают сроки или подрядчик входит в какой-то рейтинг вроде Теглайна. И всё это без учёта поддержки, обновлений, продвижения и возможных проблем с масштабированием и доработками.
Nocode-разработка обходится дешевле. Например, Сергей Горелов в одиночку собрал полнофункциональное приложение для фитнес-клуба за пару недель — такое же приложение обычная студия будет разрабатывать около полугода и возьмёт за работу 700−800 тысяч рублей.
А Евгений Спорыхин из nocode Hero вместе с WeLovEnocode запилил карьерный трекер с геймификацией на Bubble. Вместе с детализацией техзадания, доработками, дополнительными функциями и пятью итерациями по дизайну (клиент не совсем понимал, какой он хочет видеть визуальную составляющую) это заняло три месяца и обошлось заказчику примерно в 700 тысяч рублей.
Аналогичная работа «в коде» длилась бы гораздо дольше, а заказчик отдал бы не меньше 4 млн рублей. При этом первую полнофункциональную версию запустили уже через 2 недели — всё остальное ушло на доработки дизайна и добавление новых идей клиента.
Да, у мобильных приложений на зерокодинге пока есть некоторые ограничения: например, чтобы сделать массовый сервис с трафиком в десятки миллионов человек, когда критичны скорость работы и премиальный дизайн, придется создавать свое решение, нанимать программистов или отдавать разработку на аутсорс. А вот первые версии такого продукта — особенно MVP — можно собирать и без кода. Приложения на несколько десятков или сотен тысяч пользователей nocode-платформы также выдержат без проблем.
Снижение стоимости мобильных приложений неизбежно привлечет массовую категорию новых клиентов — теперь приложение может себе позволить даже скромный ИП-шник или владелец пары овощных киосков.
Игорь — профессиональный программист. Как-то раз ему понадобилось выполнить техническую задачу за пару дней — так он вошел в зерокодинг. Сначала автоматизировал на Integromat, потом перешел на Glide. А в пандемию он назерокодил приложение для обучения макияжу MAKE — помогал жене перевести бизнес в онлайн.
Игорь освоил Glide за три дня, еще 4 дня делал структуру приложения. Дольше всего вносил список из 400 продуктов — это заняло 2 недели😂 Приложение интегрировано с ЮKassой, Integromat и GetCourse, можно выбрать свой цветотип, форму лица и глаз, найти инструменты и средства для макияжа, а также получить советы — где их лучше купить, чтобы не попалась подделка.
Когда пользователь открывает приложение, система опознает его: если в Google-таблицах Access не равен Yes и нет отметки trial, то подписка неактивна и выводится экран оплаты. После оплаты подписки в Integromat запускаются две цепочки: первая — для уже зарегистрированных пользователей. Она обновляет запись об оплате в Google-таблице в строке пользователя. Вторая — для новых пользователей. Она создает новую запись в талице.
Если пользователь оплатил подписку с помощью банковской карты, информация о ней сохраняется. За 3 дня до окончания подписки пользователя предупредят о предстоящем списании. После автооплаты система пришлет результат — успешно прошло списание или денег на карте не оказалось. Эта логика собрана на GetCourse.
Как разработать мобильное приложение для своего бизнеса и не разориться
Когда бизнес заказывает мобильное приложение, есть риск переплатить или слишком сэкономить. Если переплатить, приложение может не окупиться и ударит по бюджету компании. Если слишком сэкономить, есть риск на выходе получить бесполезный и нефункциональный кусок кода.
Мы в компании Neti занимаемся разработкой мобильных приложений и хотим рассказать, как соблюсти баланс между экономией и функциональностью: потратить минимум денег и получить все, что нужно.
На стоимость разработки мобильных приложений влияют 5 критериев:
Дизайн. Чем больше у приложения экранов, пунктов меню и разделов, тем дороже дизайн.
Функционал. Здесь все также: чем больше функций, тем дороже. Калькулятор, платежи, работа с файлами, чат, подключение карт — каждая функция увеличивает стоимость приложения.
Работа на разных платформах. Если приложение нужно только для одной платформы, его стоимость будет ниже. Если нужно, чтобы оно работало и на iOS, и на Android, есть два пути:
Разработка серверной части. Если она есть или нужно подключиться к готовой системе, например, 1С, это проще и дешевле. Если нужно разрабатывать серверные механизмы, это сделает разработку дороже.
Например, нужно приложение для сотрудников розничной сети, которое показывает информацию о товарах по ценнику. Это приложение должно подключаться к серверам, где хранятся данные о товарах и с помощью машинного обучения распознаются фото ценников. Если серверная часть готова, разработать приложение будет проще и дешевле. Если ее нет, придется писать такой функционал и разработка выйдет дороже.
Тестирование. Его стоимость зависит от количества экранов и от функционала приложения.
Чтобы лучше объяснить разницу между недорогим и дорогим приложением, возьмем два примера из нашей практики.
Нам нужно было за короткий срок работать легкое и удобное мобильное приложение. Все нужные для него функции были простыми и недорогими: каталог, интеграция с картами и интернет-магазином Ленты. Для всего этого есть стандартные решения, так что разработать такое просто. Кроме того, мы сделали приложение кроссплатформенным, что помогло сэкономить еще больше.
Заказчику нужно было мобильное приложение для контроля строительства и подрядчиков. Приложение получилось дорогим из-за того, что нужны были сложные нестандартные функции: загрузка поэтажных планов из ПДФ, редактирование этих планов, обработка замечаний, синхронизация, формирование отчетов, графики и поддержка офлайн-режима. Все это нельзя было реализовать в кроссплатформенном приложении, так что мы писали два разных кода для iOS и Android. Это и сделало приложение дорогим.
Подробнее об этом мы рассказывали в кейсе у нас на сайте.
Ниже мы говорим об экономии не в ущерб качеству. Даже если вы сэкономите, вы все равно получите качественное, рабочее и функциональное приложение, удобное для пользователей. Просто приложение не будет идеальным — но зачастую идеал и не нужен.
Не добавлять лишние функции. В приложения часто добавляют функции, которые кажутся крутыми, но на самом деле не нужны. Чтобы минимизировать бюджет, на старте должен быть только критичный функционал, который решает основную задачу приложения. Универсальных советов здесь нет — все зависит от ситуации.
Например, в приложении по доставке еды из супермаркетов обязательно нужна карта, корзина, платежные инструменты, интеграция с интернет-магазином супермаркетов. А вот без отзывов или отображения иконки курьера на карте на старте точно можно обойтись.
Другой пример с приложением застройщика. На старте мы планировали добавить разные слои объектов: с пешеходными дорожками, экстерьером, деревьями или коммуникациями. Эти слои можно было бы включать и отключать. Но по факту оказалось, что этот функционал не нужен: всегда необходимо видеть полную картину, и отключать слои нет смысла. Если бы мы не анализировали поведение пользователей, понять это бы не получилось.
Еще заказчики часто просят добавить в приложение офлайн-режим: чтобы все работало без связи с сервером. На практике такое нужно очень редко, например, если это приложение для инженеров, которые работают в подвале. В остальных случаях ничего страшного не произойдет, если приложение не будет работать офлайн: мобильный интернет есть везде.
Заменять сложные решения простыми. Некоторые функции в приложении не обязательно разрабатывать — можно использовать простые и готовые решения.
Например, многие клиенты хотят, чтобы в приложении был чат. Кажется, что это просто, но на самом деле разрабатывать реально удобный чат достаточно долго, сложно и дорого. Гораздо лучше оставить ссылку на Whatsapp или Telegram и переводить человека туда. Над популярными мессенджерами уже не первый год работают сотни программистов, они поддерживают чат-ботов и легко интегрируются с CRM — и все это почти бесплатно.
Другой пример: оплата прямо в приложении. Ее можно серьезно упростить: сделать оплату через веб-сайт, чтобы окно подтверждения открывалось внутри приложения. Это быстро, удобно для пользователя и гораздо дешевле интеграции с платежными системами.
Выбрать не столичное, а региональное агентство. Работа крупных московских агентств стоит дорого: дизайнерам и разработчикам там платят больше. Чтобы сэкономить, лучше обратиться в хорошее региональное агентство — так вы получите приложение за меньшие деньги, но не потеряете в качестве и функционале.
Даже если вы московская компания, приложение можно заказать в регионе: удаленно подписать договор, общаться и передавать все результаты без личных встреч.
Neti — как раз такая компания. Мы нанимаем программистов и дизайнеров из регионов, платим им больше, чем в среднем получают IT-шники в их городах — и все равно получается дешевле, чем в Москве. В итоге стоимость приложения тоже получается ниже.
Собрать больше материалов для дизайнера. У вашей компании наверняка есть брендбуки, логотипы и другие графические материалы. Многое из них можно использовать в разработке дизайна приложения, чтобы не пришлось все продумывать и рисовать с нуля. Если вы соберете такие материалы заранее и предоставите студии, разработка приложения будет стоить дешевле.
В разработке есть критичные вещи, на которых экономить нельзя категорически. Из очевидного: базовые функции, без которых приложение не будет работать. Нельзя сделать приложение по доставке еды и не добавить туда корзину.
Но есть четыре вещи, на которых вроде бы сэкономить можно, но мы этого делать не рекомендуем:
Предварительное исследование рынка и потребностей пользователей. Важно обязательно понять, кто целевая аудитория приложения, какой функционал критически важен, как работают приложения конкурентов и какие процессы нужно автоматизировать с помощью приложения. Это стоит денег: может потребоваться провести анкетирование или опрос или заплатить маркетинговому консультанту. Но без этого есть риск создать приложение, в котором будет десяток лишних функций и ни одной нужной.
Важно, чтобы со студией общался не только начальник или менеджер, но и маркетолог, который погружен в задачи проекта и хорошо понимает его целевую аудиторию.
Дизайн. Даже идеальный функционал не сработает, если приложение будет некрасивым и неудобным. Дизайн — лицо приложения, его основа. В дизайне нельзя игнорировать принципы разработки интерфейсов — приложение будет выглядеть дешево и не понравится пользователям.
Тестирование. Чтобы сэкономить, есть соблазн пропустить этот этап: вроде бы все работает, все хорошо, приложение можно выпускать. Но так делать категорически нельзя: в процессе работы могут вскрыться какие-то критические ошибки и дыры в безопасности, которые принесут компании крупные убытки. Да и пользоваться приложением, которое постоянно ломается, никто не будет. Поэтому мы никогда не убираем тестирование из сметы и не рекомендуем на нем экономить.
Напишите в комментариях, знаете ли вы еще какие-то моменты, на которых можно сэкономить, а на которых не стоит. Может, мы что-то упустили? Было бы здорово посмотреть на опыт других разработчиков или услышать отклик от потенциальных заказчиков.
Разработка мобильных приложений: с чего начать
В нашей работе мы проходим все стадии жизненного цикла создания мобильного приложения, и я бы хотел поделиться нашим опытом в этой сфере. Под катом — рассказ об основах мобильной разработки: от выбора платформы до создания, размещения в магазине и последующего мониторинга.
Тенденции
Чем пользуются владельцы мобильных телефонов?
Статистика
За 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, а к внутренним логам обращаться при возникновении вопросов. Наша практика показывает, что такой подход оправдан: периодически наши данные и данные сервисов несколько разнятся. Если вы склонны проверять статистику, используйте разные источники.
Специфика
Заключение
Я постарался рассказать вам о базовых особенностях и подводных камнях мобильной разработки, которые встречались нам на нашем пути. Надеюсь, пост оказалась вам полезным. Если у вас остались вопросы по теме, или вы знаете что-то, что может быть полезно нам, давайте обсудим это в комментариях.