Очень часто - непосредственно перед выпуском приложения - клиент понимает, что ему нужно отслеживать активность пользователей и собирать события, или когда приложение уже выпущено, он хочет изменить инструмент аналитики. В мобильном приложении есть множество инструментов для сбора аналитики. Некоторые из них более обширны, некоторые предназначены только для создания отчетов, но большинство из них работают одинаково - вы создаете объект события и вызываете одну функцию для их сохранения, а библиотека выполняет всю грязную работу для ты. Выглядит просто, но подумайте, что, если у вас 40 экранов и вам нужно поменять Firebase на аналитику Facebook? Черт возьми ... Вам нужно найти все ссылки, изменить импорт фреймворка и заменить вызовы ... много работы, и вы знаете, что давно писали этот код ... Или другой пример - ваша компания хочет создать свою собственную систему аналитики, но в настоящее время работа ведется, и Вам необходимо поддерживать оба инструмента. Это настоящая, живая проблема, и если вы работаете в компании, занимающейся разработкой программного обеспечения, и вы работали над множеством приложений, вы понимаете, о чем я.

Начнем с определения протоколов. Конечно, когда мы хотим сделать что-то универсальным и многоразовым, нам необходимо использовать протоколы. Наше событие содержит имя - это наш ключ - параметры и userProperties, в чем разница между двумя последними? Параметры сохраняются как дополнительные данные в конкретном событии, например стоимость покупки. Свойства пользователя - это атрибуты, которые вы определяете для описания сегментов вашей пользовательской базы, таких как языковые предпочтения или географическое положение. Это также зависит от реализации инструмента, но в большинстве случаев так работает.

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

Наш «менеджер» будет проводить всех зарегистрированных провайдеров и транслировать мероприятие с необходимыми данными. Это не более чем простой агрегатор.

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

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

И вуаля! Мы можем вести журнал наших событий в любом месте!

Не так быстро! Нам нужно сделать еще один шаг ... Теперь наши события собраны в пустоту ... Нам нужно зарегистрировать провайдеров, которые связаны с внешней библиотекой.

Но прежде всего нам нужно реализовать этих провайдеров. Давайте посмотрим, как может выглядеть интеграция Firebase.

Для Facebook все будет аналогично. Вероятно, вы сможете реализовать это самостоятельно.

Привет! А как насчет тестов? Я знаю, что многие из вас - может быть, даже больше, чем меньше - не пишут тесты, но если вы это сделаете, вы поймете, что этот «микросервис» не является инъекционным. Это не проблема, Analytics - нет, но провайдеры могут быть, просто создайте TestProvider и зарегистрируйте его во время тестов.

TL;DR

Использование агрегатора аналитики помогает нам отправлять события нескольким поставщикам без изменений во всем приложении. Прочтите это! Стоит того ;)

Спасибо за чтение! Если вам понравилась эта статья, хлопайте в ладоши, чтобы другие люди тоже могли ее прочитать. У меня также будет больше мотивации для следующей статьи :) Вы также можете посмотреть другие мои статьи, возможно, вы найдете что-то для себя.

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