Опыт написания приложений для Mamba.Ru

В этом посте я поделюсь опытом и проблемами, с которыми мы столкнулись при работе с платформой приложений Mamba.

Описание платформы

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

Игры и приложения

Mamba пытается создать некую грань между приложениями и играми, хотя ситуация тут достаточно интересная. По-моему, где-то до начала 2012 года игры вообще были запрещены как таковые. Любое приложение должно, согласно правилам размещения (если оно не предназначено для знакомства), так или иначе способствовать знакомству пользователей. В пункте 4 FAQ есть оговорка, что игровой портал они делать не хотят, но при некоторых обстоятельствах игровое приложение может быть допущено.

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

API и взаимодействие с Мамбой

За некоторыми исключениями, я остался доволен представленным API. Все достаточно логично и понятно.

Первый запрос при заходе пользователя в приложение определяется по наличию в GET-параметрах соответствующих переменных. Желательно все их сохранять в сессию, так как в дальнейшем при переходах по страничкам (мы делали не flash-приложение) вам будет необходим sid — идентификатор сессии и oid — уникальный ID пользователя в мамбе. Без первого обращение к большей части API-функций невозможно.

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

После первого захода sid-ключ действует в течение четырех часов. Но фишка в том, что в документации написано «Ключ SID актуален в течение 4х часов с момента последнего запроса к серверу!». Так вот — это все неправда. Он актуален 4 часа с момента генерации. То есть, если пользователь зашел в приложение, то он сможет в нем пробыть максимум 4 часа. Дальше все api-вызовы будут ругаться и надо будет просить пользователя нажать F5, так как по-другому получить новый ключ невозможно.

Будьте готовы к тому, что некоторые части API могут переставать работать совершенно независимо друг от друга. Иногда они падают, и у нас были случаи, когда фотографии не отдавались в 1 запросе из 5. Жмем F5, а нам периодически приходят пустые данные. Как будто нет фотографий у человека.

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

Очень полезно иметь флаг — установлено ли приложение у пользователя и периодически (лучше ночью) проверять, не удалил ли его пользователь. Так как смысла отправлять таким пользователям какие-либо уведомления нет.

Генерация подписи, описанная на этой странице в приципе работает. Но помните, что $request_params не должны содержать пустых значений. Просто у нас все обращение к API было оформлено в виде класса с полями — параметрами запроса. А при запросах сервер-сервер (например, консольные крон-задачи рассылки уведомлений) поле sig было равно NULL, как не заполненное, но оно фактически было и итерировалось как и все остальные поля при формировании подписи. Понятно, что это наш косяк, но место ошибки я искал достаточно долго.

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

Секретный урл для оплаты — «URL обработчика биллинга». Вот это действительно магия. Нигде в документации вы не найдете того, как именно ваш скрипт должен отвечать на входящие запросы от мамбы при поступлении платежа. Так вот знайте, что это описано в разделе Формат ответа сервера. Да, тут речь идет именно про ваш сервер. Кроме того, независимо от того, что же вернул ваш скрипт, деньги все равно будут начислены (я не уверен что всегда, но такое случалось) — это плохо тем, что пользователь своих денег в вашем приложении не увидит и будет огорчен.

Раньше в JS-API необходимо было писать app_id прямо в теле js-скриптов, вызывающих диалоги пополнения счета. Теперь этого нет, но до того момента напрягало, так как было два приложения — одно тестовое, а другое боевое, и менять эту цифру мы иногда забывали.

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

При запросах сервер-сервер (то есть вне сессии пользователя) не забывайте выставлять secure=1, иначе ничего работать не будет.

Отправка сообщений пользователю — просто внесу ясность. Сообщения можно отправлять при активной сессии, либо не имея таковой. В первом случае сообщения можно отправлять от имени текущего пользователя только тем, кто есть у него в списке контактов. Для этого используется метод contacts.sendMessage. Во втором случае надо использовать notify.sendMessage. Но есть два момента: daily_balance, который возвращает остаток сообщений, еще ни разу на моей памяти не менялся и скорее всего просто является константой. Может потом и пофиксят. И еще имейте в виду, что уведомления доходят далеко не сразу и далеко не все.

Лучше всего данные анкеты мамбы (если вам необходимо сохранять ее полностью) хранить в Mongo. Она просто идеально подходит для хранения огромных вложенных массивов.

Браузеры

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

Если у вас есть тестовое приложение, которое работает на домене вроде my-app.local, то в опере необходимо включить «Allow Cross Network Navigation».

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

Общие замечания

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

Но в то же время, существует возможность в некоторых странах регистрировать анкеты без подтверждения телефона. Понятно, что они будут иметь некоторые ограничения в чужих регионах, но зная список таких стран можно без труда нарегистрировать анкет и совершать различного рода накрутки, если ваше приложение такое допускает (бонусы за приглашенных друзей, халявные периодические бонусы и все в этом духе). Будьте осторожны с такими вещами. Если необходимо, то можно напрочь отсекать от приложения пользователей, не подтвердивших телефон (флаг is_real в методе anketa.getFlags будет равен 0).

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

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

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

Статья написана в соавторстве с ZaiSL

Автор: deadkrolik