Введение. О мобильной разработке и об инструментах, которые мы используем
Мобильная разработка уже давно не ограничена количеством используемых инструментов. Чтобы понимать насколько их много, давайте попробуем составить список этих инструментов. Для удобства пойдем по пути начинающего разработчика, отмечая в список те инструменты, с которыми он знакомится в процессе своего обучения, развития и роста компетенций.
Рассмотрим на примере мира iOS. Когда ты только собираешься начать программировать, тебе, конечно, нужна среда разработки. Берем самый очевидный вариант – Xcode. Далее ты пишешь первое приложение, и теперь тебе надо его как-то запустить. Тут ты знакомишься с iOS Simulator. Через какое-то время ты уже в команде и делаешь задачи. Вот надо посниффить трафик – разбираешься в Charles. Влезаешь в пуши – узнаешь о Pusher. Надо подебажить приложение, а напрямую подключиться из Xсode нет возможности – идешь в Console. Начинаешь заниматься релизом – постигаешь Fastlane. Fastlane на CI ломается – постигаешь Transporter.
Также я думаю, что все мобильные разработчики рано или поздно столкнутся с Firebase и другими Google Services. Firebase – это продуктовая аналитика, анализ краш-логов, продуктовые пуши и маркетинговые рассылки, remote config, тестовые сборки и еще много чего. Я думаю, все прекрасно понимают важность каждого из этих элементов в процессе разработки и поддержки приложения.
Проблема с которой мы почти все столкнулись
Современный мир – это постоянные вызовы. Непредвиденные ситуации, отказы, поломки всегда были спутниками любого IT-продукта. В последние несколько месяцев примерно у каждой российской компании появился риск, что какой-либо из используемых ими сервисов может перестать работать в России. Поэтому перед нами встала задача обеспечить непрерывность ключевого для компании направления – мобильной разработки.
Как мы подошли к этой проблеме
Решение выглядит очень простым с точки зрения формулировки, но сложным с точки зрения реализации. Нам надо:
Проверить все сторонние зависимости в нашем приложении на возможность их отключения;
Для выбранных зависимостей подобрать замену или замены с аналогичной функциональностью;
Выбрать среди аналогов лучший. Критерии в каждом случае будут свои.
В процессе анализа зависимостей приложения мы выявили ряд инструментов, которые в теории могли бы быть отключены. Как пример, первым и самым явным можно назвать Firebase. Ранее в статье уже было упомянуто, за что отвечает данный инструмент, таким образом, риск его отключения ставил под сомнение дальнейшую возможность поддержки приложения.
Далее мы составили список функциональностей за которые эти инструменты отвечают. Ниже я расскажу для каждой из этих функциональностей: как мы их заменили, какие альтернативы рассматривали в процессе анализа (если они были конечно) и что выбрали в итоге. Стоит отметить, что прежде всего, мы рассматривали бесплатные сервисы.
Продуктовая аналитика
Продуктовая аналитика была первостепенно важной функциональностью, которой нужно было обеспечить непрерывность работы. Почти сразу после предложения и анализа мы выбрали AppMetrica.
AppMetrica
Инструмент от Яндекса, достаточно известный. Удобный и легко интегрируется. Данные с него в своей работе у нас используют продакт-менеджеры, потому что в AppMetrica наглядные и структурированные дашборды и графики из коробки.
Интеграция
Для интеграции достаточно зарегистрировать приложение на AppMetrica. Получить там ApiKey. Далее интегрируем SDK. Для этого надо подтянуть в проект зависимость YandexMobileMetrica/Dynamic/Core. Активировать сбор метрики с помощью ApiKey. Все, приложение готово отправлять события.
Но после анализа от аналитиков, поступило предложение интегрировать Snowplow.
Snowplow
Это корпоративная платформа для маркетинга и анализа продуктов. Здесь собираются все метрики для построения аналитических дашбордов по требованиям. Snowplow обладает большей функциональностью, чем AppMetrica, но всю эту функциональность надо дополнительно настраивать. Ей пользуются дата-аналитики.
Интеграция
Для интеграции нужно поднять у себя сервер. Далее интегрируем SDK, подтягивая зависимость SnowplowTracker. При настройке трекера указываем ендпоинт, через который мы ходим на сервер, поднятый ранее. Все, приложение готово отправлять события.
Поддержка обоих инструментов не сильно затратна, что дает нам возможность использовать их вместе.
Крашлитика и аналитика производительности
Хорошим и единственным аналогом для рассмотрения был Sentry. Удобный и неприхотливый в развертывании кросс-платформенный мониторинг приложений с акцентом на отчеты об ошибках. Является self-hosted решением, что гарантирует зависимость работоспособности сервиса только он нас.
Интеграция
Для интеграции, поднимаем свой сервер. Подтягиваем SDK. Активируем SDK с помощью эндпоинта. Все, приложение готово отправлять события.
Уведомления
Замена механизма для push-уведомлений была одним из самых болезненных вопросов, потому что в случае блокировки со стороны APNS альтернатив в iOS-мире нет. Только переход на СМС, что является достаточно затратным вариантом.
Отказавшись от Firebase для управления рекламными пушами, мы перешли на AppMetrica. Для сервисных пушей мы использовали и используем собственную реализацию на бекенде. Почему мы не заиспользуем это решение для рекламных пушей? Потому что для этого нужно поднять документацию по использованию и убедиться, что для рекламных пушей не понадобятся доработки. А бекенд-разработка сейчас занимается более приоритетными задачами.
Remote Config
Напомню, что remote config – это набор настроек, приходящих на мобильный клиент при старте приложения. Он настраивается на вебе и может быть разным для отдельных пользователей. Через remote config мы реализуем фича-флаги, A/B тесты и дополнительные настройки. При анализе альтернатив Firebase, выбор оказался достаточно большим.
Flagsmith
Open Source Feature Flagging and Remote Config Service
Плюсы:
Open Source
Наличие клиентского SDK
Self-hosted и on-prem
Минусы:
Ограничение в 50 000 запросов в месяц
Явно не подходит под наши масштабы.
ConfigCat
Managed feature flag service
Плюсы:
Open Source
Удобный UI
Есть поддержка A/B тестирования
Наличие опенсорсного клиентского SDK
Минусы:
Ограничение в 5 000 000 запросов в месяц
Все еще мало запросов.
Flipt
An open-source, on-prem feature flag solution
Плюсы:
Open Source
On-prem
Минусы:
Нет SDK под iOS
Достойный вариант, без ограничений. Но проигрывающий по количеству плюсов следующим вариантам.
Unleash
Is the open source feature toggle service
Плюсы:
Open Source
Удобный UI
Есть поддержка A/B тестирования
Данные загружаются json-ом
Минусы:
Open Source версия очень урезанная по сравнению с платной
Отсутствует сегментация
Мы ищем не платную версию.
Flagr
Is a feature flagging, A/B testing and dynamic configuration microservice
Плюсы:
Open Source
Бекенд с красивой оберткой
Self-hosted и on-prem
Минусы:
Нет SDK под мобилку
Не самый удобный UI
Наличие всех необходимых плюсов, отсутствие ограничений на количество запросов и доступность всего функционала в Open Source версии останавливает наш выбор на Flagr. Хоть здесь и отсутствует SDK под мобилку, для данного сервиса это не критично. Мы уже написали собственную реализацию в рамках одного спринта. Подняли сервер с вебом. Через него загрузили данные флагов и настроек. При старте приложения через наше SDK делается запрос и подтягивается Remote Config.
Рассылки тестовых сборок
На данный момент дев сборки собираются через скрипты с помощью fastlane на GitLab CI. Далее тестировщики забирают сборки из артефактов.
Google Maps
Также для полноты картины, важно отметить уход от Google Maps. Мы давно уже поглядывали на 2GIS, и теперь же нам представился шанс сделать переход. Он вышел удачным, с сохранением всей функциональности. Справедливости ради, интерфейс взаимодействия с 2GIS оказался скуднее, чем у Google Maps. Что вызвало небольшие трудности при интеграции.
Технических подробности трудностей
Особенно заметно это было при реализации отображения нескольких маркеров так, чтобы они все помещались на экране телефона. У GoogleMaps данный функционал реализуется намного проще, для этого необходимо всего лишь знать координаты нужных объектов. 2GIS же использует специфичные объекты/классы, в которые нужно обернуть координаты маркеров, чтобы отобразить их все на карте с нужным приближением/отдалением.
Здесь же стоит упомянуть работы с обработкой нажатия на маркер/кластер. В Google Maps разработчику нужно реализовать методы делегата GMSMapViewDelegate и на этом всё. В случае с 2GIS нужно на всю карту навесить UITapGestureRecognizer, который позволяет отлавливать тапы по карте. При этом нужно дописать отдельную логику, чтобы определить, был ли нажат маркер или кластер, а может иные объекты на карте.
В целом, картами от Google пользуется огромное количество разработчиков. За время их существования на просторах форумов вида StackOverflow накопилось очень много вопросов (как тривиальных, так и не очень) по части использования данного провайдера. В случае с 2GIS на помощь приходит только раздел Issues на Github. Уверены, что у коллег из 2GIS все еще впереди и их продукт будет становиться только лучше и лучше.
Заключение
Работа по поиску инструментов шла, на наш взгляд, плодотворно. Мы внедрили и уже активно используем инструменты, о которых рассказали выше. Но есть и нерешенные задачи, с которыми мы разбираемся или планируем разобраться в ближайшее время. “Доставка” тестовых сборок по сути переведена в ручной режим. Также еще думаем над более удобном инструментом для A/B-тестирования, потому что Flagr в этом плане не очень практичен. Возможно, рассмотрим написание своих инструментов.
В целом, на сколько это возможно, мы быстро смогли подготовиться к внезапным отключениям Google-инструментов и обеспечить непрерывную работу приложения, сохраняя все важные элементы функциональности и информацию, необходимую для поддержания работы и реагирования на проблемы.
