ТЕКСТ: АЛЕКСЕЙ ГАВРИЛОВ. Идея сделать «голосовую аську» возникла у меня в 2005 году, после того как поигравшись с Jimm на своей Motorola v535, я понял что ICQ на телефоне – это здорово, но очень неудобно. Проект получил кодовое имя VoICQ (voice icq) или «Васька», я написал краткое резюме, исследовал возможности современных (по тому времени) телефонов и … на этом все закончилось. У нашей команды, занятой тогда заказными разработками ни времени, ни сил тянуть свой продукт с неясными перспективами не было. Прошло два года прежде чем мы вернулись к идее и начали разработку первой версии приложения, которое решили назвать Loudtalks (дабы избежать недоразумений с владельцами торговой марки ICQ). Программа для Windows позволяла отправлять голосовые сообщения по принципу рации – нажал-говоришь-отпустил-слушаешь. Позднее были реализованы каналы для группового общения. К каждому каналу могут подключиться одновременно до 300 человек. Идея мобильного приложения продолжала витать в воздухе, но первый iPhone тогда только появился, а до момента, когда Apple откроет SDK сторонним разработчикам оставался еще почти год.
Начинаем работу
Получилось так, что ко времени, когда мы приступили к разработке приложения для iPhone, у нас уже были запущены приложения для BlackBerry и Android. Оба приложения написаны на Java, и нам удалось 80% кода использовать на обеих платформах, что сильно упростило разработку и поддержку ценой отказа от использования некоторых «вкусностей» (например, generics) доступных только в Android. Клиент для ПК был написан на C++, и нам предстояло решить – пытаться ли портировать существующий C++ код на iOS или переписать «с нуля» на Objective C. Мы выбрали Objective C и ARC с тем, чтобы упростить в будущем развитие и поддержку проекта. Пришлось отказаться от совместимости iPhone 2G, но прогресс есть прогресс.
Несмотря на кажущуюся простоту приложения, впереди была немалая работа по переводу порядка 26,000 строк исходного кода с Java на Objective C. Мы планировали закончить портирование за три месяца, однако в реальности потребовалось шесть.
Новое имя
Одновременно с запуском разработки, мы определились с новым ярким, кратким и запоминающимся именем для продукта – Zello и купили домен zello.com. Решение было непростым – мы (да и многие пользователи) уже успели привыкнуть к старому имени, но общение с носителями языка показало, что Loudtalks вызывает неоднозначную (часто негативную) оценку. На поиск нового имени мы потратили около 3 недель, рассмотрев более 1000 вариантов. Имя Zello оказалось среди множества других предложенных участниками конкурса на www.crowdspring.com и первоначально не привлекло нашего внимания (в том числе и из-за того, что домен Zello.com был уже занят). Однако, постепенно отбросив все остальные варианты, мы остановились именно на нем (решив использовать свободный домен zello.me в качестве «плана Б», если не удастся заполучить .com). Результат конкурса названий нам так понравился, что и для логотипа решили провести конкурс (на этот раз на www.99designs.com).
Тот самый логотип
Дизайн без дизайнера
Для успешного iPhone приложения необходим очень качественный дизайн и, если на BlackBerry и Android большинство приложений не отличаются красотой, средний уровень топовых приложений на iPhone чрезвычайно высок. В идеале в дизайн-команде iPhone приложения должно быть два человека – UX-дизайнер, ответственный за создание схемы взаимодействия пользователя с программой, и дизайнер графики. У нас не было ни того, ни другого. Из-за ограниченности бюджета изначально мы попытались найти одного специалиста, который смог бы совмещать обе роли и стать душой дизайна Zello.
Увы, найти такого человека оказалось крайне трудно… мы продолжаем его искать и по сей день. К январю работа по портированию движка близилась к концу и необходимо было начинать разработку интерфейса. За неимением лучших альтернатив за описание сценариев использования, создание wireframes, а впоследствии и графики пришлось взяться мне самому.
Ключевыми критериями оценки интерфейса были приняты простота (использовать приложение должно быть возможно одной рукой не глядя на экран) и максимально возможное применение стандартных элементов и метафор пользовательского интерфейса. За две недели были нарисованы, как тогда казалось, окончательные варианты схем всех экранов приложения. Рисовал я их карандашом на листах A4, потом фотографировал и отправлял по e-mail, чтобы обсудить по скайпу с командой.
Так выглядел самый первый вариант wireframes
Экран на котором пользователь будет проводить больше всего времени – это экран разговора с определенным человеком или группой. Царит здесь кнопка push-to-talk. Чтобы не перегружать экран решили историю сообщений сделать «складной». От раскрывания ее по клику как и от табов пришлось отказаться, так как при использовании приложения пользователи часто задевали ладонью края дисплея, что приводило к ложным переключениям экранов.
Эволюция экрана разговора
Исходя из того, что большинство людей постоянно общаются не более чем с пятью контактами, в качестве второго по значимости экрана мы определили экран со списком недавних вызовов. Он позволяет быстро перейти к нужному контакту или увидеть пропущенные сообщения.
Про аппаратные кнопки и фоновый режим
В процессе разработки возникла идея – использовать аппаратную кнопку громкости (одну из двух) в качестве переключателя передачи. Повесив обработчик на обратный вызов аудио системы об изменении громкости можно отловить факт нажатия, отработать это событие и вернуть громкость назад. К сожалению, при этом невозможно отследить отдельно факт нажатия и отпускания, а кнопка не может выполнять свою основную функцию, что может запутать пользователя и противоречит требованиям Apple, поэтому от идеи пришлось отказаться. Зато в последнем обновлении мы добавили возможность использовать кнопку гарнитуры в качестве переключателя передачи (первое нажатие – начало передачи, второе – остановка) – работает это, в том числе, и c отключенным экраном, и когда приложение выполняется в фоне.
Про работу в фоне стоит сказать отдельно. Нам хотелось, чтобы приложение могло принимать и сразу проигрывать входящий звук, даже когда экран выключен или приложение свернуто с тем чтобы можно было всегда оставаться на связи. Начиная с iOS4 и iPhone 3GS для VoIP приложений такая возможность доступна – при переходе в фон приложение останавливается, как обычно, но при получении входящих данных система его будит, позволяя выполнить их обработку. Однако при этом есть несколько неочевидных особенностей. Во-первых, если ваше приложение слишком часто просыпается (чаще чем 15 раз в течение 5 минут), то оно будет принудительно завершено системой для экономии энергии. В нашем случае это происходило, если подключиться к каналу, из которого как раз с такой частотой приходят сообщения. Оказалось, впрочем, что система сама перезапускает приложение в этом случае, так что оставалось лишь убедиться, что код корректно отрабатывает при автоматическом рестарте без участия пользователя. Во-вторых, приходится считаться с тем, что кроме вашего приложения на телефоне используются и другие программы записывающие или проигрывающие звук (например, собственно телефон). Приложения, используемые последними имеют преимущество (перехватывают аудио фокус) и ваше приложение утрачивает возможность проигрывать звук до момента, пока пользователь снова его активирует. В нашем случае такое поведение почти фатально – программа неожиданно перестает принимать входящие сообщения. Чтобы сгладить проблему при обнаружении потери аудио фокуса Zello автоматически активирует статус «Занят». В этом режиме входящие сообщения принимаются, но не проигрываются сразу (попытка это сделать приводила бы к ошибке), а попадают в историю сообщений, откуда их можно прослушать позднее. При этом используются системные уведомления, чтобы сообщить о новых сообщениях.
App vs Apple
Наконец релиз готов, протестирован и отправлен в App Store. Через неделю приходит отказ. Причина – не предоставлена информация необходимая для тестирования приложения. Действительно, для использования программы необходима учетная запись, но ведь при первом старте можно ее создать. Вероятно тестировать процесс создания аккаунта цензорам не интересно – создаю им два аккаунта и отправляю заново. Через неделю – опять отказ. Причина – «указанные вами учетные записи не работают». Как же так, проверяю и перепроверяю – все работает. Смотрю еще раз на присланный скриншот и обнаруживаю, что имя на скриншоте (appletest1) отличается от того, которое мы указали в описании (apptest1) и сообщение об ошибке вполне красноречиво об этом говорит – «Убедитесь что вы правильно указали имя пользователя и пароль». Пишу ответ с просьбой внимательнее вводить имя пользователя, а заодно создаю еще пару аккаунтов с именами как на присланном скриншоте. Еще через два дня, приложение уходит в review и меньше чем через 10 минут – уже одобрено!
Эволюция иконки приложения. От первоначальной идеи нарисовать «алюминиевую» иконку отказались в пользу более строгой и контрастной.
Первые успехи
В течение двух недель с момента запуска Zello успело побывать в общих топ-10 App Store в 22 странах, суммарное число загрузок на сегодня – больше миллиона. Лучший результат в российском App Store – 14 место в категории «Социальные сети». Каждый день (на всех платформах) приложение используют более миллиона человек. Приложение бесплатное и без рекламы, ближе к концу лета планируем выпустить платную версию с дополнительными возможностями.
Цена: Free [iTunes link]
А голосовые сообщения можно прослушивать повторно? Ведь тогда это получается урезанный клиент VoIP. Особенности служб обмена мгновенными сообщениями в том, что клиент не всегда может находиться онлайн и не всегда рядом с устройством, их можно перечитывать или читать когда появляется возможность. Если голосовые сообщения хранятся на сервере, тогда сервис превращается в сервис голосовой почты. Отсюда вопрос в возможности обеспечения безопасности и стабильности соединения для хранения и загрузки сообщений.
@Whilser, Прослушивать повторно можно из истории сохраненной на устрйстве. Если вы не онлайн, сообщения для вас примет сервер и отправит push-уведомление. Как только сообщение доставлено клиенту с сервера оно удаляется.