«ПроАптека» — это профессиональное объединение более 6000 независимых аптек, созданное при участии одного из крупнейших фармацевтических холдингов — «ПРОТЕК». Мы разработали для них маркетплейс, а теперь — маркетплейс в кармане :)

Заказчик попросил, чтобы приложение умело все то же, что и сайт: и корзину с оформлением заказов, и оплаты, и доставку — и все это должно работать на бэкенде сайта. Ух!

Раз приложение дублирует функционал сайта, то можно перейти на карманную версию, не заметив этого:

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

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

Дизайн приложения основывается на дизайне сайта.

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

Приложение разрабатывалось на кроссплатформенном фреймворке React Native, и благодаря ему один и тот же код используется и для Android, и для iOS.

Классика разработки приложений — нативная, где используются оригинальные языки программирования мобильных ОС и разработка ведется в средах разработки, созданных специально под эти ОС: для iOS в среде Xcode, на языках Objective-C, Swift, C и С++, а для Android — в среде разработки Android Studio и на языке Java.

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

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

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

Чтобы приложение полностью дублировало функционал сайта, мы не стали делать отдельный бэкенд для него, а сделали REST API. Он связывает фронтенд мобильного приложения с бэкендом сайта. Таким образом, на одном бэкенде работает и сайт, и приложение (сайт напрямую, а приложение через API). И все работает одинаково, ведь для каждого функционала есть методы в API. Например, оплаты работают через бэкенд сайта: вы нажимаете «Оплатить», открывается нативный от приложения попап и там открывается страница оплаты, та же самая, что и на сайте.

Все методы REST API мы писали с нуля, а для разработки и тестирования использовали Swagger — фреймворк для проектирования, создания, документирования и использования веб-сервисов RESTful. В итоге имеем единый документ API, который можно передать другому разработчику и тот разберется за несколько минут.

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

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

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

Мы используем Google, Apple и Яндекс.Карты, так как большая часть функционала завязана на геокодировании адресов пользователей. Некоторые службы доставки требуют точные координаты и город пользователя. Координаты в буквальном смысле — долгота и широта :)

Мы сделали способ определения координат универсальным для всех доступных сервисов доставки:

• Яндекс.Такси
  
• Dostavista
  
• Gett
  
• Доставка ПроАптеки
  

Если пользователь разрешил приложению определять местоположение, то точный адрес рассчитывается автоматически. Если разрешения нет, то пользователю предлагается выбрать адрес на карте самостоятельно, передвигаясь по ней. Android такая идея понравилась, а с iOS сюрприз — после десятого движения выводилось сообщение, что запросов сделано слишком много, и работать дальше ничего не будет. Мы сделали интеграцию с Яндекс.Картами, чтобы во всех случаях, когда Google Maps и Apple Maps не смогли определить адрес, Яндекс мог их подстраховать и геокодировать адрес.

При повторном заказе приложение подтянет адрес из профиля пользователя.

Это кроссплатформенный приложение, которое эмулирует работу других приложений (а на программистском языке — фреймворк для нативных React-приложений). EXPO можно скачать себе на девайс из Play Market или AppStore и посмотреть, как ваше приложение будет себя вести до публикации в сторы. Билды приложения загружаются в EXPO и еще до релиза в сторы можно запустить приложение на устройствах и посмотреть, как оно будет работать в боевом варианте.

Куда установлено EXPO — там и будет работать ваше приложение с учетом модели устройства и его операционной системы (работает для Android, iOS и web-приложений на JavaScript и React). А чтобы передать заказчику во время разработки приложение на посмотреть или утвердить, не нужно писать инструкции по установке и использованию приложения. Заказчику достаточно установить приложение EXPO себе на устройство, через QR-код скачать билд и при обновлении билда на нашей стороне будет обновляться и билд в EXPO у заказчика для приемки работ.

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

Мы эмулировали ситуацию, когда в приложении одновременно находились 1000 пользователей, и, к примеру, 100 из них открыли каталог (=запросили каталог по API) одновременно (как по команде на 3−2-1), а мы смотрели, выдержит ли приложение. Если какое-то единовременное действие этих пользователей не выдерживало нагрузку, смотрели причину и оптимизировали метод API, который отвечал за это действие. Конечно, такие эмулируемые ситуации нереальны, но, а вдруг.

А время запросов в итоге зафиксировали в миллисекундах :)