Android

Со смартфоном все сияет: мобильная жизнь клинеров

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

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

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

Заказчик

«Мегаклин» — российская мультисервисная компания, специализирующаяся на комплексном обслуживании объектов недвижимости.

Основные направления деятельности:

  • клининг;
  • контроль и поддержка инженерных систем зданий;
  • аутстаффинг — предоставление наёмного персонала.

Объекты «Мегаклин» — торгово-развлекательные площадки, моллы, бизнес-центры, автосалоны, спортивные и медицинские учреждения, производственные комплексы.

Руководство «Мегаклин» ещё до сотрудничества с Энтеррой выступало за преобразования и внедрение современных способов ведения бизнеса. Например, компания использовала Beacon-маяки для контроля персонала непосредственно на объектах. Beacon-маяк — это небольшое беспроводное устройство, передающее радиосигналы с помощью Bluetooth 4.0. Сигнал сенсоров распространяется на расстояние от 20 сантиметров до 70 метров.

Однако этого было недостаточно, чтобы все функционировало на 100%. В результате «Мегаклин» обратился к нам за разработкой мобильного приложения.

Трудовые будни и мобилизация

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

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

Веб-панель администратора

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

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

Цветовая маркировка заданий

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

Список заданий в работе

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

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

Оценка выполненной работы

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

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

Пользователи и права

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

Важные детали

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

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

Техническая сторона проекта

Для разработки приложения «под ключ» и тестирования потребовалось 5 месяцев. Команда проекта состояла из семи человек: четырех разработчиков, тестировщика, дизайнера и менеджера-аналитика.

Технологии и компоненты: сервер и базы данных – Windows Server, MS SQL; приложение для Android – Xamarin; панель администрирования – web-приложение на базе Enterra CMS.

В результате…

Разработанная система сделала все коммуникации в компании прозрачными и эффективными.

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

И самое главное – все необходимое для эффективной работы под рукой. В любом смартфоне на базе Android.

Синий кит Mobi DB, или немного о мобильных базах данных и совсем ничего – о китах и романах Меллвила.

 

Мы создали очень полезное приложение Mobi DB, которое помогает удобно хранить самые разные личные данные. Чтобы «подальше расположить», чтобы потом «поближе взять», свои CD и DVD коллекции, списки задач, покупок, книг, рецепты, списки продаж, расходы, контактные данные и другую важную личную информацию – как раз и нужен Mobi DB.

 

MobiDB1

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

 

MobiDB2

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

 

MobiDB3

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

 

MobiDB4

А вот так будет выглядеть карточка конкретного заказа в базе данных.

 

MobiDB5

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

 

MobiDB6

Если кому-то не хочется создавать свои базы данных с нуля, в Mobi DB есть 19 редактируемых шаблонов, которые можно настроить до полного соответствия своим требованиям. База для продаж цветов как раз создана на одном из них. Как и при создании базы с нуля, можно дополнять её, упрощать или наоборот – усложнять в визуальном редакторе. Вдобавок можно экспортировать и импортировать в приложение другие базы данных и шаблоны, а также подключаться к уже существующим на других носителях базам данных.

 

MobiDB7

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

 

MobiDB8

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

 

MobiDB9

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

 

MobiDB10

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

Mobi DB создан на C# с использованием фреймворка для кросс-платформенной разработки мобильных приложений Xamarin. Для статистики и отслеживания исключений мы использовали Google Analytics, для сканирования баркодов – библиотеку Zxing.

С одной стороны, всегда есть соблазн сделать приложение сразу для нескольких платформ. Но, с другой стороны, Xamarin не дает возможности писать кроссплатформенный пользовательский интерфейс. Поэтому перед разработкой кроссплатформенного решения всегда требуется определить, сколько кода можно будет разделить между кросс-платформенной частью и UI. Может оказаться в итоге, что эффективней использовать “нативные” приложения для Вашего проекта.

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

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

mobi

 

На этом пока все. До новых встреч!

 

ChinookBook – купонное приложение

Enterra выпустила в июле очередную версию активно распространяемого на территории США купонного приложения ChinookBook для iOS и Android. Мы рады завершению очередного этапа в развитии продукта, над которым работаем уже более двух лет.

 

Предистория:
Сначала компания Celilo Group Media из Портленда, США, хотела «просто» перевести в электронный вид продажу пользователям купонов со скидками на потребительские товары или услуги. Компания со своими особенностями. Например, она сотрудничает только с теми производителями и продавцами товаров или услуг, которые используют максимально дружественные к окружающей среде технологии или возобновляемую энергию (Green Business). Также её бизнес имеет годовую цикличность и поэтому выпуск новых версий приложения желательно координировать с массовым выпуском купонов, который происходит в августе (Big Launch). На этот раз придумывать дизайн от нас не потребовалось, поскольку оформление целиком предоставлял заказчик. В общем, задача сводилась к тому, чтобы через свеженькое и вовремя вышедшее приложение ChinookBook пользователи приобретали купоны и получали актуальную информацию о выгодных или ближайших к их местоположению продавцах товаров и услуг.

ChinookBook

Купон «2 за 1» и защитная анимация.

Использовать приложение очень просто – приобретенный с его помощью купон пользователь должен показать на экране айфона продавцу в магазине и при нем же нажать кнопку redeem, чтобы аннулировать купон в системе учета. Для защиты от особо хитрых и жадных пользователей были сделаны фигуры внизу экрана. При активном и подключенном к системе приложении они слегка движутся. Глядя на них продавец может убедиться, что покупатель действительно потратил скидочный купон. С самой первой версии iOS-приложения, которая вышла в сентябре 2011 года, был реализован независимый от Аppstore (а позже и от Google Play на Android устройствах) механизм оплаты купонов через приобретенную карточку с кодом или независимую электронную платежную систему.

Чтобы дальше по тексту лучше понимать как это работает, нужен небольшой экскурс в навигацию приложения. Пользователь первой версии ChinookBook мог ознакомиться с торговыми предложениями несколькими способами. Во-первых, в первой версии потребитель мог выбрать один из всего двух маркетов – Портланда или Сиэтла (маркет включает не только сам город, но и его ближайшие пригороды). Во-вторых, после выбора маркета пользователь мог применить несколько типов навигации:

  • Выбрать ближайшее к его местоположению предложение в меню Near Me по карте (Map) или предложению купонов (List).
  • В меню Coupon осуществить поиск купонов по категориям («рестораны», «здоровье и стиль», и т.д.)
  • В меню My пользователю доступны сообщения о новинках (Messages), избранные им по предпочтениям купоны (Favorite Coupons),  статистика по экономии на покупках (Savings).
  • В меню Resources прочитать ознакомительные статьи.
  • В меню More управлять купонами, маркетами, аккаунтами, прочитать справку о компании Celilo Group Media.

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

cbm-iphone-coupons-catlist
Выбор в меню Coupon по категориям.

Первые усовершенствования:

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

Default

ChinookBook 1.2.0

Поэтому в вышедшем через восемь месяцев, в апреле 2011, обновлении ChinookBook 1.2. были добавлены меню Trial Coupons (купоны, срок действия которых начинает отчитываться с момента приобретения пакета купонов) и специальная категория Latest Deals!, которая показывает новые предложения, а также – фильтр купонов. Поддержка Push-notifications позволила приложению получать уведомления, даже если оно не запущено. Для отслеживания заказчиком потребностей пользователей приложение стало посылать статистику на сервис Flurry. Ещё мы внедрили систему мониторинга состояния сервера, которая посылает заказчику предупреждение в случае ошибки приложения.

013-cbm-iphone-coupon-view-1a

Пример реализации покупки определенного купона.

Ещё через некоторое время у заказчика появились спонсоры, которые захотели размещать в приложении свои логотипы. Это было сделано в октябре 2011 года с выходом версии 1.3. ChinookBook. Логотипы спонсоров появились на экранах My и My Savings (для каждого маркета – свой спонсор) и в разделе Resources (в каждой группе ресурсов свой спонсор). В дополнение была упрощена регистрация новых пользователей. География присутствия Celilo Group Media расширилась и в приложении появились три новых маркета, а пользователи получили возможность редактирования списка категорий купонов (и сопутствующих им изображений). Связанный с этими апгрейдами рост количества данных привел к тому, что мы изменили процедуру создания начальной базы данных и синхронизации. В результате ресурсы и группы ресурсов стали активными или не активными. Не активные ресурсы не синхронизировались с устройствами.

Бизнес американской компании становился всё более интенсивным, поэтому для вышедшей уже в декабре 2011 года iOS версии ChinookBook 2.0. вместе с заказчиком мы разработали несколько дополнений. Основная задача – привлечь новых пользователей и более активного вовлекать их в скорейшее использование первого бесплатного купона. При этом ChinookBook должен был остаться привычным и очень простым в использовании продуктом для покупки пакетов купонов. Во-первых, для этого появились Welcome packs – назначаемые при создании нового аккаунта бесплатные пакеты купонов с ограниченным сроком действия. Во-вторых, недавно зарегистрировавшимся, или купившим полный пакет купонов, пользователям рассылается Weekly deals – еженедельно высылаемый специальный набор купонов. Третья новинка – Communication Tools – короткие сообщения, которые помогают тратить купоны. Ну и наконец, о каждом продавце, который предоставил купоны для приложения, формируются Merchant Profile – короткие справочные материалы. Для обработки возросшего объема информации были расширены возможности push notification.

022-cbm-iphone-nearme-merchant-nostream

Merchant Profile

Разработка Android версии:
Ну и, конечно же, нельзя было оставить неохваченными пользователей Android устройств. Параллельно с iOS версией 2.0 Enterra разработала приложение ChinookBook под Android и выпустила его в апреле 2012 года. По сути, это был перенос iPhone приложения на платформу Android OS с незначительными упрощениями. Усложнило задачу желание заказчика полностью сохранить исходный дизайн. Гайдлайн Android пришлось проигнорировать. Функционал версии в итоге оказался полностью аналогичен iPhone приложению, несмотря на различия в особых рекомендациях разработки интерфейсов под Android OS. Серверная часть не подвергалась значительной переработке и обеспечивает работу с обеими платформами, дополнена только специфическими для платформы технологиями (нотификации через C2DM вместо APN и т.п.)

Отвязка части купонов от маркетов:
Очередные шаги Celilo Group Media в работе с пользователями и всё большая география использования Chinook Book привели к тому, что нам пришлось «отвязывать» некоторые купоны от определенного маркета и создавать категорию купонов для групп пользователей. В сентябрьской прошлогодней версии ChinookBook 2.5 для iOS и Android также была внедрена функция Communities. Пользователь теперь мог стать участником сообщества (например, Nike) и получать купоны, выпускаемые только для группы. Но самые большие усилия в разработке этой версии понадобились для создания Multiple-Market packs, которе объединили купоны без привязки к одному маркету. Эта доработка потребовала значительных усилий из-за использования привязок к маркету во многих местах проекта. Заодно мы не упустили возможности обработать и разные не связанные между собой RFC (Запросы на комментарии) и багфиксы.

Качественный скачок:
Растущий бизнес компании-заказчика привел к открытию новых маркетов, появлению тысяч новых предложений и необходимости синхронизации всего этого. Настал момент внести большие изменения в приложение. Версия ChinookBook 2.6, выпущенная в декабре 2012 года, претерпела самые серьезные изменения с начала разработки продукта. Она отличалась более совершенной экономичностью. Так, были увеличена скорость работы программы (Device Speed Improvement) и с 25 до 7 мб снижен размер, сокращен трафик. Благодаря функции Device Syncing приложение поставлялось без начальной базы, а данные для разных маркетов скачивались отдельно через сеть доставки/дистрибуции контента (CDN). Синхронизация тоже происходила не по всем маркетам, а только по выбранным. Синхронизировались также только измененные картинки, а приложение и сервер были переведены на работу с UTC (Всемирное координированное время). Обновлены и алгоритмы работы с купон паками и хранения некоторых сущностей в серверной БД. Управление изображениями перенесено в БД, добавлена синхронизации избранного.

 

021-cbm-iphone-nearme-maplocations2

Меню Near Me, Портленд.

Более поздние iOS и Android версии ChinookBook 2.7. функционировали с марта 2013 года и уже с трудом удовлетворяли растущие потребности клиента и пользователей. От предыдущей версии они отличались тем, что приложение для Android переведено с устаревших нотификаций C2DM на современные GCM, реализована более совершенная работа с Community, а для маркетов добавлена возможность Multiple Market Centers – иметь множественные центры (ранее был один). Для сохранения информации применена новая процедура Upgrade с сохранением текущих данных. Также приложения обслуживали значительно расширенный ареал, выросший уже до 11 маркетов:

  • Боулдер;
  • Денвер;
  • Ист Бэй;
  • Орегон (только предприятия-участники “Blue Sky wind power program”);
  • Портленд;
  • Сан-Франциско;
  • Санта-Круз;
  • Сиэтл и Пьюджет-Саунд — поселения в системе заливов на территории штата Вашингтон, США;
  • Силиконовая Долина;
  • Миннеаполис и Сент Пол;
  • Юта (только предприятия-участники “Blue Sky wind power program”);

Сейчас:

Вышедшая третья версия приложения стала стабильнее в работе, она может сортировать купоны не только по алфавиту, но и по дате истечения срока их действия, обладает расширенными функциями по защите приватности, а некоторые экраны сделаны удобнее. Особо стоит отметить реализацию в ChinookBook 3.0 новой функции Make a Shopping List – объединение купонов в список, который можно активировать у продавца целиком, нажав только одну кнопку  Redeem. Эта функция сильно упрощает покупки в одном магазине сразу по нескольким купонам на разные товары или услуги.

ChinookBook2

Меню Shopping Lists, формируется список, один купон уже включен, один – нет.

Растущая география работы приложения порождает взрывной рост объема данных, с которыми оно должно работать.  У компании Celilo Group Media также постоянно возникают новые идеи и новые предложения для пользователей. Именно поэтому ChinookBook постоянно приближается к совершенству, но никогда его не достигает. Мы не боимся это признать – это особенность любого развития. Встречайте версию 3.0, любите и критикуйте её – мы сделаем ещё лучше.

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

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

Давайте разберем варианты монетизации подробнее.

 

Freemium

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

Другой вариант Freemium-модели позволяет скачивать полную версию игры бесплатно, но при определенных ограничениях (например, разрешено построить только одно здание в сутки). В таких играх ограничение снимается при покупке премиум аккаунтов. К слову, 34% из ТОП-100 кассовых приложений в App Store используют модель Freemium.

Варианты/идеи применения Freemium метода в игре:

  • предоставление HD версии игры;
  • увеличение количества уровней;
  • увеличение скорости игры;
  • предоставление дополнительных функций/возможностей;
  • увеличение количества персонажей;
  • покупка аккаунта с расширенными возможностями.

Примеры игр: Angry Birds, Cut the Rope, Angry Birds Space HD, Fruit Ninja.

Free-to-Play

Проекты, построенные на Free-to-Play модели, не требуют денег за игру. Разработчики таких игр зарабатывают на удобстве пользователей. Хочешь, чтобы здания строились быстрее – плати, хочешь переодеть своего героя в новую одежду – плати.

В подобные игры вкладывать деньги не обязательно, но без удовольствия от игры будет неполным. Основная задача разработчика сделать игру так, чтобы пользователь, как можно чаще использовал платные возможности. По статистике в США около 90% внутриигровых трат приходится на Free-to-Play модель.

Варианты/идеи применения Free-to-Play метода в игре:

  • покупка игровой валюты;
  • покупка опыта в игре;
  • покупка виртуальных предметов;
  • увеличение скорости игры;
  • покупка одежды для персонажа;
  • покупка подарков;
  • покупка оружия;
  • покупка vip аккаунта.

Примеры игры: Jetpack Joyride, Resort HD, Веселая ферма.

Рекламная модель

Игры, разработанные  с использованием этой модели, показывают своим пользователям рекламу. Зачастую такую модель используют с какой-либо другой моделью монетизации, например, c моделью Freemium. Примером такой игры является игра Angry Birds, где в бесплатной версии (demo) внедрена реклама. Большой прибыли с такого варианта монетизации получить практически нереально, только если вы не создатель игры с миллионной аудиторией.

Варианты/идеи применения рекламной модели с Freemium методом:

  • удаление рекламы;
  • уменьшение количества рекламы.

PAID

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

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

Недавнее исследование ученых из Кембриджского университета показало, что 73% всех приложений в Google Play — бесплатные и 80% из них полагаются на монетизацию через встраивание рекламных баннеров. По числу загрузок бесплатные приложения намного превосходят платные: из последних только 20% загружаются более 100 раз и 0,2% — более 10 000 раз; с другой стороны, 20% бесплатных приложений скачиваются 10 000 и более раз. Как видим, данный метод монетизации уступает предыдущим.

Примеры приложений и игр: HD Виджеты, Swype Keyboard, World of Goo

Комбинированный метод

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

  • Freemium + Рекламная модель
    Данный метод использовали разработчики ROVIO MOBILE в разработке своей игры Angry Birds. В демо-версию игры разработчики ограничили количество уровней и встроили рекламу. В полной же версии игры отсутствовала реклама  и искусственное ограничение на количество уровней.
  • Freemium + Free-to-Play + PAID + Реклама
    Компания EA разработала игру The Sims™ в которой были совмещены сразу  четыре системы монетизации: игра была выпущена в бесплатной и платной версии, а также в игре присутствуют элементы Free-to-Play модели (например, в игре необходимо развиваться и получать за это очки, которые можно тратить на различные улучшения в доме). Также есть возможность покупки очков за реальные деньги. В бесплатной же версии, кроме прочего, присутствует реклама.

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

В каком маркете прибыль выше?

С каждым днем в Google Play  и App Store загружается огромное количество приложений и с каждым днем все сложнее добраться до заветного ТОП’а!

Google Play растет значительно быстрее чем «яблочный» App Store. По количеству загрузок приложений Google Play уже превзошел магазин от Apple. Однако, выручка с приложений для iOS значительно больше, чем для Android.

По оценкам аналитиков Canalys, за январь – март все магазины приложений в мире заработали 2,2 миллиарда долларов. Из них на долю Apple пришлось 1,48 миллиарда, т. е. около 74%, а на долю Google – всего 18%. Тем не менее компания Google показывает очень быстрый рост. По сравнению с аналогичным периодом прошлого года продажи в GooglePlay выросли на 90 процентов, а продажи в AppStore – всего на 25 процентов.

По прогнозам аналитиков, GooglePlay продолжит уверенный рост, но вряд ли сможет опередить Apple до 2016 года.

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

На этот вопрос постаралась ответить компания App Annie, которая предоставляет аналитику по скачиваниям и продажам для всех мобильных платформ.

Загрузки приложений: App Store vs. Google Play

Загрузки Google Play составили около 90% загрузок App Store в первом квартале 2013 года.

Доходы от приложений: App Store vs. Google Play

App Store получил в 2,6 раза больше доходов от приложений, чем Google Play, в первом квартале 2013 года.

С четвертого квартала 2012 года по первый квартал 2013 года квартальный доход App Store вырос примерно на четверть. Между тем, доход от приложений Google Play вырос примерно на 90%.

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

Давайте теперь взглянем на наиболее перспективные категории с точки зрения загрузок и прибыли.

AppStore: ведущие категории по загрузкам в 1 квартала 2013 года 
(Фото- и видео-приложения достигли ТОП-3 по загрузкам)

  1.  Игры
  2. Развлечения
  3. Фото и видео, +1*
  4. Утилиты, -1*
  5. Стиль жизни

* изменение индекса в сравнении с предыдущим кварталом

Категория «игры» остается абсолютным лидером, как источник роста в App Store и дает около 40% загрузок магазина в 1 квартале 2013 года. Категории «Фото» и «Видео» поднялись по показателям загрузок и вырвались в ТОП-3 в 1 кв. 2013 г.

AppStore: ведущие категории по доходам в 1 квартале 2013 года
(Игры лидируют, но у образовательных приложений лучше с монетизацией)

  1. Игры
  2. Производительность
  3. Социальные сети
  4. Образование, +1*
  5. Развлечение, -1*

* изменение индекса в сравнении с предыдущим кварталом

Категория «Игры» продолжает бурный рост в доходах, обеспечивая около 70% доходов App Store в 1 квартале 2013 года. Категория «Образование» также приносит доход, что позволяет ей продвинуться на 4 позицию.

GooglePlay: Ведущие категории по загрузкам в 1 квартале 2013 года.
(GooglePlay становится более социальным) 

  1. Игры
  2. Инструменты
  3. Развлечения
  4. Коммуникации
  5. Социальные сети, +1*

* изменение индекса в сравнении с предыдущим кварталом
В Google Play категория «Игры» стабильно росла на протяжении предыдущего года. Категория «Соц. сети» также показывает стабильный доход в загрузках и в настоящий момент занимает 5 место.

GooglePlay: ведущие категории по доходам в 1 квартале 2013 года 
(Игры дают больший доход в GooglePlay, чем в AppStore)

  1. Игры
  2. Коммуникации
  3. Социальные сети
  4. Инструменты
  5. Производительность

По состоянию на 1 кв. 2013 года категория «Игры» выросла и обеспечила около 80% доходов Google Play по сравнению с 70% в App Store.

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

Средние цены на iOS-приложения по каждой категории для iPhone и iPad

Компания Distimo опубликовала среднюю стоимость приложений для iOS.

Из этих графиков мы видим, что средняя стоимость приложений для iPhone приблизительно $2, а средняя стоимость для iPad – $3. При этом если учитывать, что категория «Игры» самая популярная среди всех прочих, то смело можно утверждать, что разработка игр для мобильных устройств по-прежнему очень прибыльное занятие. Приложения в категориях «Навигация», «Бизнес» и «Производительность» по-прежнему продолжают быть самыми дорогими.  По сравнению с прошлым годом средняя цена на приложения для iPhone выросла на 16%, а для iPad упала на 8%.

Аналитика продаж

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

Отличным помощником в этом является сервис компании App Annie http://www.appannie.com/ru/, который наряду с ежедневными рейтингами показывает наиболее приятные с эстетической точки зрения графики изменения этих самых рейтингов. На графиках удобно отмечать различные знаковые события, например, снижение цен или релиз новой версии. Бесплатная регистрация дает возможность разработчикам подключать детальную статистику по их приложениям, как описано здесь: http://www.appannie.com/ru/app-store-analytics/.

Но не стоит также забывать и о сборе статистики о действиях пользователей из самой игры. В этом может помочь такой сервис, как Flurry (http://www.flurry.com/). Flurry предоставляет отчеты о действиях пользователей, а также информацию о самих пользователях: пол, возраст, географию и т. д. Если вы все же привыкли к интерфейсу Google, то можно использовать Google Analytics, который ни чем не хуже Flurry.

Вывод средств из App Store в России для ИП

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

Проблема заключается в том, что валютный контроль банков не пропускает перевод без сопроводительных документов (договора и паспорта сделок), а Apple, к сожалению, их не предоставляет. В России на идентификацию денежных средств согласно валютному законодательству дается 15 дней, после чего идет сообщение в ЦБ. При отсутствии необходимых документов деньги остаются на транзитном счете и пользоваться ими нельзя. Отсюда и возникают “подвисшие” сотни и тысячи долларов, которые не могут получить разработчики.

Можно, конечно, быстро слетать на другой континент, открыть счет в местном банке и оформить пластиковую карту, а после этого ждать 2-3 месяца пока Аpple по запросу обновит платежные данные. Но, например, для жителей Украины такой вариант практически неприемлем, поскольку гражданам этой страны можно открывать счета в зарубежных банках только с особого разрешения ЦБ, да и стоимость открытия счета за рубежом и накладных расходов так же может отъесть значительную часть прибыли.

Самым оптимальным вариантом для начинающего разработчика, неважно – компании или индивидуального предпринимателя, является работа через издательскую компанию. При этом разработчик сможет сберечь значительное время на ожидание регистрации своего членства в iDP – издатель сразу же сможет предоставить доступ программистам к закрытому девелоперскому порталу и разрешить генерировать сертификаты для подписывания и запуска на реальных устройствах программ при разработке. Так же, как правило, сотрудники издателя обладают достаточно большим опытом не только в разработке, но и в продвижении программ в App Store и разработчику всегда есть к кому обратится за помощью.

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

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

  1. “iOS Paid Applications Agreement”  и его перевод на русский язык, заверенный вашей печатью ИП (нотариус не нужен).
  2. Два листочка с финансовыми реквизитами (вашими и Apple), так же заверенные вашей печатью.
  3. Если сумма не превышает 50000$ за время действия контракта, то паспорт сделки оформлять не нужно. Если поступит больше – то заблаговременно сообщите банку и они оформят паспорт сделки на основании документов №1 и №2.

Статью подготовил Скорик Дмитрий

P. S. Если статья оказалась полезной, не забывайте лайкать и репостить.

“Морской бой: Противостояние” для Android

Мы намеренно анонсировали выход нашего нового продукта, игры “Морской бой: Противостояние”, только в твиттере, оставив самое вкусное для этого блога. И дождались.

 

Screenshot_1

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


Подытожим и перейдем к плюсам/минусам. Итак, что мы имеем:

  • поиск противников вокруг и возможность играть по каналам Wi-Fi/Bluetooth;
  • игра с виртуальным противником в режиме однопользовательской игры;
  • ностальгический, тетрадный, дизайн боевых полей;
  • возможность размещения кораблей вручную или в автоматическом режиме;
  • использование стилуса или пальцев для управление игрой;
  • потрясающие визуальные и звуковые эффекты лишь немного не дотягивающие до экранизации игры;
  • постоянно обновляющийся Зал Славы;
  • возможность приобретения дополнительного вооружения через Samsung In-App Purchase.

Игра «Морской бой: Противостояние» со всеми ее достоинствами и нововведениями, бесспорно, станет одной из Ваших любимых игр.

Достоинства:

  • Классический морской бой с тетрадным дизайном
  • Игра по Wi-Fi/Bluetooth
  • Дополнительное вооружение: радар, авианалет, мина.

Недостатки:

Единственный существенный недостаток – сейчас игра доступна только владельцам телефонов и планшетов Samsung, но думается это только пока.

Оценка: 4/5

Ссылка на приложение в Samsung Apps: http://www.samsungapps.com/mars/topApps/topAppsDetail.as?productId=000000529895


Полную версию впечатлений от игры читайте на сайте android.mobile-review.com.

Новогодний марафон

“Каждый год, 31-го декабря, мы с друзьями ходим в баню” (с) Евгений Лукашин

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

 

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

Мобильные разработки

Как сообщает “мобильная” команда, уходящий 2012 год прошел под знаком iOS. О чем свидетельствуют записи тут, здесь, там и еще вот. И чуть не забыли про это.

 

При чем здесь Android?

– Пойдем простым логическим путем.
– Пойдем вместе.
(с) Ирония судьбы…

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

Enterra Poker

Развитие платформы Enterra Poker продолжалось и будет продолжаться. В 2012 году, к существующим версиям (флэш версия, десктоп версия, социальная версия), мы предложили мобильную версию клиента.

Разумеется, на 2013 год обещано много нового. Команда разработчиков уже сейчас готовит подарки в виде новых версий платформы Enterra Poker, в которые войдут новые игры и продукты, игровые особенности и возможности, полезные функции и другие необходимые изменения.

Конкурсное новогоднее оформление было поддержано абсолютно всеми отделами и департаментами. Ниже представлена фотоподборка от Perpetuum Software, Адаптивных технологий, отделом Java и .NET разработок.

— Куда вы меня несете?
— Навстречу твоему счастью.
(c) Ирония судьбы…

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

С наступающим Новым 2013 годом, друзья! В Новый год вместе с Энтеррой!

 

SmartLocker для Android

Новое приложение для Android SmartLocker освобождает от постоянного ввода пароля и автоматически снимает блокировку телефона при нахождении аппарата в доверенной Wi-Fi сети.

Отмечайте в настройках те Wi-Fi сети, при нахождении в которых вам не требуется блокировка телефона от посторонних, например дома или в офисе.

Screenshot SmartLocker 

SmartLocker распространяется бесплатно через онлайн-магазин Google Play. Поддерживаются устройства на базе операционной системы Android версии 2.1 и старше.

 

Портфолио, как украшение интерьера

В связи с расширением производства недавно мы сменили место дислокации и обосновались в новом офисе бизнес-парка «Статус».

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

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

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

 

Android. Особенности работы с SQLite.

Тепикин Егор

В настоящее время все большую популярность набирает OS Android. С ростом популярности платформы расширяется и круг задач, которые пользователь хочет решить здесь и сейчас. Среди задач встречаются такие, которые требуют обработки большого объема данных за приемлемое время, так, например, полнотекстовый поиск по базе. В качестве базы данных на OS Android используется SQLite. Для работы с SQLite существует пакет android.database.sqlite. Однако данный пакет содержит только набор инструментов для работы с базой. Он не является фреймворком, регламентирующим подход к реализации доступа к данным.

На данный момент Google не предоставляет подробных рекомендаций по работе с базой данных. В официальной документации приводится лишь 2 простых примера, использующих SQLite (“NotePad” и “SearchableDictionary”). Поэтому программисты сами вырабатывают собственные подходы к реализации работы с базой данных, и, как результат, возникает множество различных способов – зачастую неверных.

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

  1. database is locked – возникает при многопоточной записи в базу.
  2. database is closed – может возникнуть при работе с базой из разных частей программы, например, Activity и Service.
  3. corrupted database – возникает, если файл базы данных был испорчен либо пользователем, либо при неожиданном прерывании записи в базу (выключение телефона, ошибка OS, нехватка пространства, битые сектора на SD карте и т.д.)
  4. низкая производительность при работе с базой данных – может возникнуть из-за внутренних блокировок, конкурирующих транзакциях, высоком уровне журналирования, отсутствии пакетной обработки.

Рассмотрим подробно как причины возникновения и возможные «неявные» проявления данных проблем, так и методы их решения.

Проблема “database is locked” (она же многопоточность)

У программистов часто возникают вопросы “Как лучше работать с SQLiteOpenHelper“. Действительно – поскольку к слою доступа к данным может обращаться практически любая часть программы (сервис, presenter, widget … ), то SQLiteOpenHelper должен быть доступен везде, где есть Context. Также встает вопрос, стоит ли для каждой части программы создавать свое соединение с базой, увеличится ли от этого скорость выполнения запросов. Возникают вопросы о многопоточном доступе к базе, и, конечно, о блокировках при записи.

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

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

  1. Если вы пишете из двух потоков одного соединения, то один поток будет ждать, пока закончит писать другой.
  2. Если вы пишете из двух потоков разных соединений, то произойдет ошибка – ваши данные не запишутся в базу, а приложение вылетит с SQLiteDatabaseLockedException.

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

Разные соединения в одном SQLiteOpenHelper

Всем известно, что SQLiteOpenHelper имеет 2 метода предоставляющих доступ к базе getReadableDatabase() и getWritableDatabase(), соответственно для чтения и записи данных. Однако в большинстве случаев реальный сonnection один. Более того, это один и тот же объект:

SQLiteOpenHelper.getReadableDatabase()==SQLiteOpenHelper.getWritableDatabase()

Это означает, что нет никакой разницы, с помощью какого из этих методов читать данные. Но гораздо важнее другая недокументированная особенность – внутри класса SQLiteDatabase есть собственные блокировки – переменная mLock. Блокировки для записи на уровне объекта SQLiteDatabase, а поскольку на чтение и запись экземпляр SQLiteDatabase один, то чтение данных тоже блокируется. Особенно хорошо это видно при записи большого объема данных в транзакции.

Помимо внутренних блокировок класс SQLiteDatabase имеет еще одну интересную особенность: данный класс (до API 11) позволяет создавать транзакции только в режиме exclusive transaction. Из-за этого при активной работе с БД могут возникать задержки. Рассмотрим пример приложения, которое при первом старте должно в фоне скачать большой объем данных(~7000 строк содержащих BLOB) и сохранить их в базу. Если данные сохранять в транзакции, то сохранение занимает ~45сек, но при этом пользователь не может пользоваться приложением, поскольку все запросы на чтение заблокированы. Если же данные сохранять маленькими порциями, то процесс обновления данных затягивается на достаточно долгий срок (~10-15 минут), зато пользователь может все это время без каких-либо неудобств безболезненно пользоваться приложением. “Палка о двух концах” – или быстро, или удобно. Причины данной проблемы и некоторые выводы более подробно освещены в статье Kevin Galligan “Android Sqlite Locking”.

Как же бороться с данным “стандартным” поведением? В новых версиях Android, начиная с API 11, Google уже начали исправлять часть проблем связанных с работой SQLiteDatabase – были добавлены такие методы как:

beginTransactionNonExclusive() – создает транзакцию в “IMMEDIATE mode”.

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

isDatabaseIntegrityOk() – проводит проверку целостности базы данных.

Более подробно описано в документации.

Однако для старых версий Android тоже необходим данный функционал.

Решение

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

SQLiteDatabase.setLockingEnabled(false); Отменяет использование внутренней блокировки запросов – на логическом уровне java класса (не связано с блокировками в терминах SQLite).

SQLiteDatabase.execSQL(“PRAGMA read_uncommitted = true;”); Позволяет читать данные из кеша. По сути, изменяет уровень изоляции. Данный параметр должен устанавливаться для каждого соединения заново. Если соединений несколько, то оказывает действие только на то соединение, которое вызвало данную команду.

SQLiteDatabase.execSQL(“PRAGMA synchronous=OFF”); Изменить способ записи в базу – без “синхронизации”. При выключении данной опции, база данных может быть повреждена при неожиданном сбое системы, либо отключении питания. Однако согласно документации SQLite некоторые операции при выключении данной опции выполняются более чем в 50 раз быстрее.

К сожалению не все PRAGMA поддерживаются в Android, например “PRAGMA locking_mode = NORMAL” и “PRAGMA journal_mode = OFF” и некоторые другие не поддерживаются. При попытке вызвать данные PRAGMA приложение вылетит с ошибкой.

В документации для метода setLockingEnabled сказано, что данный метод рекомендовано использовать лишь в том случае, если вы уверены, что вся работа с базой ведется из одного потока. Нам придется самим гарантировать, что в единицу времени будет выполняться только одна транзакция. Также вместо транзакций по умолчанию (exclusive transaction) нужно использовать immediate transaction. В старых версиях Android (ниже API 11) нет возможности создать immediate transaction через java обертку, однако сам SQLite данный функционал поддерживает. Для инициализации транзакции в immediate mode нужно выполнить следующий SQL запрос напрямую к базе данных,- например через метод execSQL.

SQLiteDatabase.execSQL(“begin immediate transaction”);

Поскольку инициализируем транзакцию мы прямым запросом, то и завершать её нужно аналогично: SQLiteDatabase.execSQL(“commit transaction”);

Осталось только реализовать свой TransactionManager, который будет инициировать и завершать транзакции нужного типа. Задача TransactionManager – гарантировать, что все запросы на изменение (insert, update, delete, DDL запросы) происходят из одного потока.

Проблема “database is closed”

При работе с базой из одной Activity через SQLiteOpenHelper, очевидно, что открывать базу нужно с открытием Activity, а закрывать при закрытии Activity. Но если с базой работает одновременно несколько Activity, несколько Service и часть данных расшаривает ContentProvider, то возникает вопрос: “когда следует открывать и закрывать соединение с базой?”. Если открывать и закрывать соединение после каждого запроса,- то скорость обращения к базе упадет в разы, а если открывать при старте приложения и закрывать при выходе,- то непонятно, когда мы выходим из приложения (а если сервис еще работает, или провайдер еще используется – остается только метод Application.onTerminate()). Но не один из этих методов не является верным. Соединение с базой может закрыться автоматически при следующих условиях:

Если несколько Activity независимо друг от друга будут открывать новые соединения, то может возникнуть ошибка, описанная в предыдущем пункте “database is locked”.

Если открывать соединение с базой при старте приложения и закрывать при Application.onTerminate(), то соединение с базой может закрыться само при очередном вызове Cursor.getCount() или Cursor.onMove(). Если детально просмотреть исходный код соответствующих классов, то видно, что при определенной комбинации условий в конечном итоге будет вызван метод SQLiteDatabase.onAllReferencesReleased(), который вызывает нативный метод dbclose(). Более детально данная проблема освещена здесь, последовательность вызовов и необходимые условия описаны тут.

Возможно, это одна из причин, по которой “ManagedCursor” объявили “Deprecated”.

Данная проблема широко известна и для ее решения предложено множество способов.

Вариант 1

При каждом обращении к базе проверять,- закрыта база или нет, и если закрыта, то переоткрывать её заново.

public synchronized SQLiteDatabase getReadableDatabase() {        
        SQLiteDatabase db;
        try {
            db = super.getReadableDatabase();
        }
        catch (SQLiteException e) {
            Log.d(Constants.DEBUG_TAG, e.getMessage());            
            db = reopenDatabase(dbFile.getAbsolutePath(), null);
        }
        return db;
    }

У данного метода есть очевидный недостаток – если мы обратились к базе, а затем сохранили ссылку на уже открытый экземпляр, и используем полученный экземпляр, не вызывая SQLiteDatabase.getReadableDatabase(), то данный метод не сработает.

Вариант 2

Принудительно добавить фиктивную ссылку на базу и держать её пока база используется SQLiteClosable.acquireReference();

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

Вариант 3

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

Вариант 4

Использовать ContentProvider для доступа к базе. Причем желательно использовать именно один провайдер – это легко реализовать, поскольку ему можно добавить неограниченное количество Uri. Суть заключается в том, что ContentProvider сам следит за состоянием базы данных. А вопрос о том, когда базу пара закрывать ложится на OS – она сама удалит старые провайдеры из памяти и вернет их при первой необходимости.

Про работу с ContentProvider подробное описание есть на официальном сайте.

Проблема “corrupted database”

На Android телефонах очень мало места отводится под приложения и это место нужно беречь, иначе пользователь пожертвует вашим приложением в пользу очередной игрушки. Почти все приложения используют базу для хранения данных, и если база слишком большая, то её очень желательно хранить на SD карте. Старые версии Android (2.2 и ниже) не позволяют создавать базу на SD карте через стандартные средства SQLiteOpenHelper, но это можно обойти, если использовать AndroidConnectionSource от ORMLite.

Нужно помнить – все, что видно пользователю может быть удалено. Пользователь может удалить или иным образом испортить файл базы данных, может вынуть SD карту из телефона, и многое другое. Но база может быть испорчена не только пользователем. Телефон – устройство с ненадежным питанием – часть данных может не записаться (особенно актуально – если отключено журналирование), база может быть повреждена при скачивании или при использовании предустановленной базы и т.д. Более подробно, о причинах порчи базы можно узнать из статьи “How To Corrupt An SQLite Database File”.

Если разработчик никак не реализовал алгоритм восстановления базы, то Android сам создаст базу заново. Но бывают случаи, когда базу можно восстановить. Самый простой способ – запросить данные из всех доступных таблиц и вставить в новую базу. Но чаще достаточно выполнить команду “VACUUM” – данный метод пересоздает базу и восстанавливает максимум данных.

Очень часто есть необходимость создать приложение с предустановленными данными. Для этого можно собрать готовую базу и положить в папку raw, а в момент установки приложения база будет скопирована на устройство. Файл с базой лучше расположить именно в папке raw. Папка assets кажется более удобной, поскольку подвергается сжатию, но из данной папки невозможно получить данные объемом более 1 мб ([см. здесь), и поэтому приходится разбивать базу на отдельные файлы по 1мб – что весьма неудобно. Важно, что базу всегда нужно собирать именно на эмуляторе самой младшей из поддерживаемых версий. Поскольку если собрать предустановленную базу на Android 2.3, то на Android 2.2 возникнет ошибка “corrupted database”, хотя на устройствах 2.3 и выше база будет работать корректно.

Оптимизация запросов

Скорость выполнения запросов складывается из множества факторов, но наиболее важными из них являются оптимизация самого запроса и структура базы данных. Для оптимизации запросов есть множество стандартных методов, которые достаточно легко найти в интернете, поэтому перечислим особенности оптимизации именно для SQLite. Для краткости оформим их в виде тезисов.
Не нужно писать запросы, которые возвращают более 1000 строк или данные объемом более 1мб. Всегда используйте оператор limit. Если запрос возвращает более 1000 строк, то будет выдано предупреждение в лог, либо произойдет падение приложения – это зависит от количества свободной памяти и самого устройства. Если нужно отображать длинный список есть два решения:

a) нужно запрашивать список частями, а затем соединять при помощи android.database.CursorJoiner.

b) Реализовывать авто дополняемый список на интерфейсе (список с догрузкой).

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

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

Если нужно создать таблицу из уже существующих данных, то используйте INSERT AS SELECT (не выполняйте отдельные INSERT) – это значительно ускорит время выполнения.

Если вы получили из базы много данных за раз, и этот “большой” запрос повторяется не часто, то очищайте ненужную память SQLiteDatabase.releaseMemory().

В операторе where нужно сначала писать более простые условия.

SELECT * FROM tablename WHERE col1 LIKE ‘%string%’ AND col2 = 123456

работает в 3-4 раза медленнее чем

SELECT * FROM tablename WHERE col2 = 123456 AND col1 LIKE ‘%string%’

Правильное индексирование таблиц ускоряет выполнение запросов в 5-7 раз. Индексировать нужно в первую очередь те поля, по которым идет join, затем те по которым идет поиск. Причем лучше указывать направление работы индекса – например

CREATE INDEX index_name ON table_name (column_name ASC).

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

Заключение

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

Хотите использовать наш опыт в разработке приложений на Android? Начните с оценки Вашего проекта прямо сейчас!

Создание мобильных приложений для бизнеса. Взгляд компании-разработчика

 

Ким Островский, руководитель мобильных проектов

11 июля 2008 года компания Apple объявила о запуске магазина приложений App Store – обновления для iTunes Store. У пользователей iPhone и iPod появилась возможность устанавливать через магазин проверенные приложения сторонних разработчиков.

В октябре этого же года компания Google запустила свой сервис Android Market для мобильных устройств под управлением Android.

Спустя несколько месяцев, в апреле 2009 года компания RIM объявила о запуске App World для BlackBerry, а в октябре 2010 в гонку включилась компания Microsoft со своим сервисом Windows Phone Marketplace для устройств под управлением Windows Phone 7.

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

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

У бизнеса появилась еще одна площадка для привлечения клиентов и, в первую очередь, это касается компаний, деятельность которых связана с распространением медиа-контента и услуг через интернет. Одним из ярких примеров выхода на рынок мобильных приложений в России стало появление в стандартной поставке серии телефонов марки LG под управлением Android приложения-гида “Афиша”, разработанного для издания компанией Энтерра. Мы также помогли выйти на рынок компании Mail.ru со своим Агентом для iOS и, чуть позже, компании Rambler с приложением “Rambler News”.

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

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

Причин у этого желания несколько:

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

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

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

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

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

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

Стремление не отстать от конкурентов

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

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

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

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

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

Намерение расширить клиентскую базу

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

Желание продемонстрировать свой статус

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

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

Чаще всего это означает желание создать собственный интернет-бизнес по подобию уже существующих сервисов или воплотить в жизнь оригинальную идею.

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

В случае с оригинальной идеей также есть свои подводные камни.

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

Во-вторых, ее стоит проверить на оригинальность.

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

Желание повысить лояльность клиентов

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

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

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

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

Донести цели проекта до подрядчика

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

Выразить свое видение проекта

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

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

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

Указать сроки и расставить приоритеты

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

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

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

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

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

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

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

Разобраться с дизайном

В зависимости от приложения, под дизайном понимается:

  • проработка расположения стандартных элементов на экранах приложения и подготовка необходимого минимума – иконок, стартового экрана, подбор цветовой гаммы;
  • добавление собственных элементов управления и отображения информации;
  • подготовка полного набора экранов приложения в рамках отдельной дизайн-фазы.

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

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

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

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

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

Подготовить данные

Очень часто в рамках проекта требуется интеграция с базой данных, где хранится и обрабатывается информация, используемая в приложении. В рамках данной задачи разрабатывается спецификация обмена данными и затем по полученному документу проводятся работы на сервере. Разработка спецификации обычно ложится на подрядчика. Работы на сервере могут быть также проведены подрядчиком (тем же или сторонней фирмой), либо специалистами компании-заказчика. Спецификация API – достаточно формальный документ и реализовать по нему требуемый функционал не составит труда, если вы поддерживаете базу данных своими силами. Если нет – вам потребуется предоставить подрядчику доступ к серверу и заплатить за работу.

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

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

Определить ответственного за проект

Сама по себе необходимость распределить ответственность очевидна, однако не всегда это распределение сопровождается предоставлением достаточного количества времени на работу с подрядчиком и наделением представителя заказчика соответствующими полномочиями. Если срок является критичным, рекомендую согласовать календарный план работ и максимально разгрузить вашего представителя на время подготовки SoW и ТЗ, старта проекта и финального тестирования. На этих стадиях разработчикам необходима быстрая реакция на возникающие вопросы, иначе есть шанс затянуть старт проекта или не уложиться в сроки. Такой же риск возникает, если представитель заказчика не наделен полномочиями принимать решения по проекту или привлекать своих специалистов для решения запланированных задач – время на согласование может значительно сдвинуть сроки выпуска приложения.

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

Публикация приложения включает в себя следующие этапы:

  • загрузка файла приложения;
  • размещение информационных материалов;
  • рассмотрение приложения администрацией и принятие его в магазин.

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

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

Для ряда платформ после публикации приложение проверяется сотрудниками магазина. У Apple это может занять от одной до четырех недель, для RIM примерно столько же, у Microsoft до недели, Google принимает приложения без задержек.

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

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

В первом случае подрядчик будет являться компанией-разработчиком мобильных приложений, но при этом вы будете указаны в качестве владельца приложения. Минус подхода – если подрядчик по каким-то причинам не сможет поддерживать свое членство в портале разработчиков, вам придется публиковать приложение заново от своего имени, с потерей рейтингов и отзывов.
Вариант с собственной учетной записью лишен этого недостатка, но требует определенных денежных затрат и времени на регистрацию. Для Apple и Microsoft цена составляет $99 в год, для Google – разовый платеж $25, для RIM – бесплатно. На регистрацию лучше заложить две – три недели.

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

Надеюсь, эта статья прояснила некоторые вопросы и дала вам верное направление в развитии своего мобильного приложения. Удачи вам и вашим проектам!

Хотите использовать наш опыт в разработке мобильных приложений? Начните с оценки Вашего проекта прямо сейчас!