Если вы работаете над проектом с большой посещаемостью и контентом, отчасти (или полностью) формируемым пользователями — то, скорее всего, у вас уже были мысли, что неплохо бы сделать мобильный клиент. Так и мы, работая над нашим проектом, решили, что пользователи будут охотнее пользоваться нашим проектом и активнее создавать новый контент. К тому же — мы ведь можем облегчить жизнь пользователя, так почему бы и нет.
И мы сделали. Осторожно, много картинок и текста.
Наиболее популярные мобильные платформы в России, на данный момент — iOS и Android. Решили писать сначала для iPhone.
Итак, есть портал с огромной базой ресторанов, баров и кафе, накопленной за его долгую жизнь. Помимо базы ресторанов есть огромное количество отзывов о них.
Случалось ли вам попадать в ситуацию, когда придя в заведение с друзьями, вы обнаруживали, что там нет мест, или шумно, или накурено, или ещё по какой-то причине вам сегодня оно не подходит? Лично я и мои коллеги в таких ситуациях бывали. Первое, о чём думаешь — есть ли где-нибудь недалеко заведение, в котором можно провести вечер? Мы решили помочь пользователю в данной ситуации.
Начали думать над взаимодействием пользователя и приложения. Стали накидывать какие-то схемы интерфейса.
Сделали API для общения приложения с базой портала. Для экономии трафика, более быстрой загрузки данных, да и потому, что данные в БД хранятся в этом виде, решили передавать их в JSON. Тогда ещё не вышла iOS 5, в которой появились публичные средства для работы с JSON, посему взяли json-framework.
Для навигации в приложении мы использовали UINavigationController вместе с UITabBarController. Пока изучали вопрос их совместного использования в приложении, пришли к двум вариантам:
Нам больше понравился второй вариант, его мы и использовали. Описание реализации обоих вариантов слегка выходит за рамки этого поста, поэтому, если кому интересно — пишите в личку, дам ссылку на описание + примеры (в личку — дабы избежать хабраэффекта).
Итак, начали мы с помощи в описанной выше ситуации — что есть рядом. Первое, что видит пользователь, запустив приложение (после экрана загрузки, конечно) — карта. Сценарий прост:
В качестве БД в нашем проекте используется CouchDB. Для выборки ресторанов в рамках окна приложения используется поиск по bounding box вместе с модулем geocouch. Приложение передает в API границы окна, а БД делает выборку заведений в этом «прямоугольнике». Все остальные запросы в БД задействуют стандартную документо-ориентированную структуру БД. Например при добавлении отзывов мы создаем в документе дополнительные поля, которые позволяют легко найти отзывы, оставленные с определенного девайса и пр. Координаты для заведений мы получаем из геокодера Яндекс.Карт, в данный момент в приложении используются карты Google (встроенный framework MapKit), но в ближайшем будущем (после стабильного релиза) мы планируем перейти на использование Яндекс.Карт, тем более, что города России у них представлены гораздо полнее.
Результат на скриншоте:
Данные подгружаются с помощью обычного асинхронного запроса через NSURLConnection, дабы не блокировать пользовательский интерфейс на это время.
Второй экран — это заведения, метки которых на данный момент успели загрузиться на карте, только в виде списка и с расстоянием до них. Что порадовало — в Objective-C у класса CLLocation есть встроенный метод distanceFromLocation для определения расстояния между двумя точками на карте (лично я, бегло погуглив, не горел желанием делать расчёт по выданным мне в результатах формулам). Понятно, что этот расчёт не учитывает того, что нужно двигаться не по прямой, а по дорогам/переходам, значение не является точной длинной маршрута от текущего места до заведения, да и определение координат пользователя может дать погрешность или не успеть определить его местоположение более точно. Но, тем не менее, эта информация может быть полезна и сыграть решающую роль, особенно если дело происходит зимой в лютый мороз и хочется побыстрее дойти/добежать. Или у вас пятница :)
Экран с информацией о ресторане/баре содержит в себе краткую информацию о заведении, новости и отзывы пользователей с портала. Само собой — каждый отзыв или новость можно открыть и прочитать. Текст новости/отзыва также подгружаются с портала через API и выводятся через UIWebView — на портале в отзывы можно вставлять изображения/фотографии, хотелось, чтобы они были видны и пользователям приложения.
Конечно же, нам хотелось, чтобы пользователи могли написать отзыв прямо из приложения. Сидите, вы, например, в известном ресторане — а вам кофе уже 40 минут не несут. Достали приложение — написали негативный отзыв о заведении (поверьте, менеджеры ресторанов читают отзывы и принимают их во внимание).
Написание отзыва, дабы не захламлять достаточно ограниченный экран телефона, было решено разбить на 3 экрана:
После добавления отзыва — он добавляется в БД сайта, посему виден и пользователям портала, и пользователям мобильного приложения. Добавление фотографий делается также через API с помощью PUT-запроса.
Конечно же, каждая подобная история должна содержать в себе часть про то, как набивались шишки с App Store.
Первую версию приложения мы отправили в App Store в начале октября. Попала туда она с 3-го раза, каждая попытка занимала примерно неделю. Дважды нам отказывали, и, наверное, по тем же причинам, что и всем приложениям, завязанным на геолокации.
Первый отказ: попросили демонстрационное видео, т.к. ревьюверы не поняли, как работает приложение, а мы этой ситуации почему-то не предвидели. Они запустили приложение, открылась карта где-то в штатах. И всё. Поскольку база ресторанов и баров наша содержит лишь информацию по городам России и Эстонии — ничего более ни на карте, ни в списке — они не увидели. Мы записали видео, отправили приложение на ревью повторно.
Второй отказ: мы выбрали доступность приложения по всему миру, а оно полноценно работает только в России и Эстонии. Неделя коту под хвост, выбрали нужные страны и отправили снова. С 3-й попытки приложение прошло ревью.
Сейчас у нас уже запланирован довольно большой объем работ по приложению. Есть куда расти, к чему стремиться, да и вообще мы только в начале пути. По странному стечению обстоятельство — пока оно только для iOS 5 (ещё один наш недосмотр), но на этой неделе мы надеемся выложить версию с поддержкой 4-й версии.
Приложение весит всего 200 килобайт, если вам стало интересно — мы будем рады видеть вас среди наших пользователей: ссылка на приложение.
И мы сделали. Осторожно, много картинок и текста.
Наиболее популярные мобильные платформы в России, на данный момент — iOS и Android. Решили писать сначала для iPhone.
Сценарий использования
Итак, есть портал с огромной базой ресторанов, баров и кафе, накопленной за его долгую жизнь. Помимо базы ресторанов есть огромное количество отзывов о них.
Случалось ли вам попадать в ситуацию, когда придя в заведение с друзьями, вы обнаруживали, что там нет мест, или шумно, или накурено, или ещё по какой-то причине вам сегодня оно не подходит? Лично я и мои коллеги в таких ситуациях бывали. Первое, о чём думаешь — есть ли где-нибудь недалеко заведение, в котором можно провести вечер? Мы решили помочь пользователю в данной ситуации.
Начали думать над взаимодействием пользователя и приложения. Стали накидывать какие-то схемы интерфейса.
Реализация
Сделали API для общения приложения с базой портала. Для экономии трафика, более быстрой загрузки данных, да и потому, что данные в БД хранятся в этом виде, решили передавать их в JSON. Тогда ещё не вышла iOS 5, в которой появились публичные средства для работы с JSON, посему взяли json-framework.
Для навигации в приложении мы использовали UINavigationController вместе с UITabBarController. Пока изучали вопрос их совместного использования в приложении, пришли к двум вариантам:
- UINavigationController внутри UITabBarController — каждый ViewController внутри UITabBarController позволяет «углубиться» дальше, но при этом всё это в рамках конкретного таба. По такому принципу работает клиент Dropbox для iPhone. Схематичный пример на видео.
- UITabBarController внутри UINavigationController — мы видим визуально то же самое, что и в первом случае, но «углубление» просмотра происходит внутри самого приложения. По такому принципу работает клиент ВКонтакте для iPhone. Схематичный пример на видео.
Нам больше понравился второй вариант, его мы и использовали. Описание реализации обоих вариантов слегка выходит за рамки этого поста, поэтому, если кому интересно — пишите в личку, дам ссылку на описание + примеры (в личку — дабы избежать хабраэффекта).
Итак, начали мы с помощи в описанной выше ситуации — что есть рядом. Первое, что видит пользователь, запустив приложение (после экрана загрузки, конечно) — карта. Сценарий прост:
- запуск приложения;
- определение местоположения пользователя;
- подгрузка заведений, координаты которых внутри видимой на экране области (bounding box);
- отображение меток на карте.
В качестве БД в нашем проекте используется CouchDB. Для выборки ресторанов в рамках окна приложения используется поиск по bounding box вместе с модулем geocouch. Приложение передает в API границы окна, а БД делает выборку заведений в этом «прямоугольнике». Все остальные запросы в БД задействуют стандартную документо-ориентированную структуру БД. Например при добавлении отзывов мы создаем в документе дополнительные поля, которые позволяют легко найти отзывы, оставленные с определенного девайса и пр. Координаты для заведений мы получаем из геокодера Яндекс.Карт, в данный момент в приложении используются карты Google (встроенный framework MapKit), но в ближайшем будущем (после стабильного релиза) мы планируем перейти на использование Яндекс.Карт, тем более, что города России у них представлены гораздо полнее.
Результат на скриншоте:
Данные подгружаются с помощью обычного асинхронного запроса через NSURLConnection, дабы не блокировать пользовательский интерфейс на это время.
Второй экран — это заведения, метки которых на данный момент успели загрузиться на карте, только в виде списка и с расстоянием до них. Что порадовало — в Objective-C у класса CLLocation есть встроенный метод distanceFromLocation для определения расстояния между двумя точками на карте (лично я, бегло погуглив, не горел желанием делать расчёт по выданным мне в результатах формулам). Понятно, что этот расчёт не учитывает того, что нужно двигаться не по прямой, а по дорогам/переходам, значение не является точной длинной маршрута от текущего места до заведения, да и определение координат пользователя может дать погрешность или не успеть определить его местоположение более точно. Но, тем не менее, эта информация может быть полезна и сыграть решающую роль, особенно если дело происходит зимой в лютый мороз и хочется побыстрее дойти/добежать. Или у вас пятница :)
Экран с информацией о ресторане/баре содержит в себе краткую информацию о заведении, новости и отзывы пользователей с портала. Само собой — каждый отзыв или новость можно открыть и прочитать. Текст новости/отзыва также подгружаются с портала через API и выводятся через UIWebView — на портале в отзывы можно вставлять изображения/фотографии, хотелось, чтобы они были видны и пользователям приложения.
Отзывы из приложения
Конечно же, нам хотелось, чтобы пользователи могли написать отзыв прямо из приложения. Сидите, вы, например, в известном ресторане — а вам кофе уже 40 минут не несут. Достали приложение — написали негативный отзыв о заведении (поверьте, менеджеры ресторанов читают отзывы и принимают их во внимание).
Написание отзыва, дабы не захламлять достаточно ограниченный экран телефона, было решено разбить на 3 экрана:
- написание текста отзыва + прикрепление фотографий;
- информация о визите (дата/тип обслуживания/оценки);
- рекомендации и добавление самого отзыва.
После добавления отзыва — он добавляется в БД сайта, посему виден и пользователям портала, и пользователям мобильного приложения. Добавление фотографий делается также через API с помощью PUT-запроса.
App Store
Конечно же, каждая подобная история должна содержать в себе часть про то, как набивались шишки с App Store.
Первую версию приложения мы отправили в App Store в начале октября. Попала туда она с 3-го раза, каждая попытка занимала примерно неделю. Дважды нам отказывали, и, наверное, по тем же причинам, что и всем приложениям, завязанным на геолокации.
Первый отказ: попросили демонстрационное видео, т.к. ревьюверы не поняли, как работает приложение, а мы этой ситуации почему-то не предвидели. Они запустили приложение, открылась карта где-то в штатах. И всё. Поскольку база ресторанов и баров наша содержит лишь информацию по городам России и Эстонии — ничего более ни на карте, ни в списке — они не увидели. Мы записали видео, отправили приложение на ревью повторно.
Второй отказ: мы выбрали доступность приложения по всему миру, а оно полноценно работает только в России и Эстонии. Неделя коту под хвост, выбрали нужные страны и отправили снова. С 3-й попытки приложение прошло ревью.
Сейчас у нас уже запланирован довольно большой объем работ по приложению. Есть куда расти, к чему стремиться, да и вообще мы только в начале пути. По странному стечению обстоятельство — пока оно только для iOS 5 (ещё один наш недосмотр), но на этой неделе мы надеемся выложить версию с поддержкой 4-й версии.
Приложение весит всего 200 килобайт, если вам стало интересно — мы будем рады видеть вас среди наших пользователей: ссылка на приложение.
