Как внедрить аналитику и не сломать приложение?

[soul_survivor]

Использование рефлексии совершенно избыточно, почему нельзя использовать обычный ООП?

interface Collector {
      fun track(event: Event)
}
class CollectorImpl : Collector {
      override  fun track(event: Event) {
             when(event) {
                     is AppStartEvent -> trackAppStart(event)
             }
      }
     private fun trackAppStart(event: AppStartEvent) {
     }
}

[ilsosnin]

Есть несколько моментов:
1) Человеческий фактор, написав новый ивент легко забыть добавить его в when
2) Когда ивентов становится много, этот when начинает очень сильно разрастаться
По сути обход классов рефлексией — это замена этого when и сокращение рисков при добавлении новых или рефакторинге старых ивентов.
Ну и не стоит бояться рефлексии, если она помогает решить задачу и сократить время разработки. В андроиде и так рефлексия повсюду, причем гораздо более тяжелая по перфомансу.

[ChPr]

написав новый ивент легко забыть добавить его в when

А вот если бы Event был sealed class'ом, то не забыли бы. Но вот разрастание when'a никак остановить не получилось бы. Как вариант размазать этот when по куче маленьких классов-обработчиков конкретного типа события.

[yanisbiziuk]

1) Достаточно перед when(event) написать val result = when(... и kotlin сам начнет ругаться если вы не обработали какой-то кейс
2) Ничего страшного в разрастании нет, а вот использование рефлексии вносит не очевидное поведение в программу.

[kenrube]

В сторону AOP не смотрели? Аналитика — это как раз одна из немногих задач, которые хорошо ложатся на эту парадигму: https://habr.com/ru/company/yandex/blog/280117/

[ilsosnin]

У нас есть довольно много параметров, которые собираются по ходу дела. И откуда их нужно брать зависит от контекста. Что затрудняет применение этого подхода. Кроме того, затаскивать АОР ради аналитики не очень целесообразно.

[houligan]

Расскажите подробнее про LStat.
Он используется исключительно для мобильных приложений, или для веб-трекина тоже?

[ilsosnin]

LStat (Lamoda Statistics) — это внутренняя система аналитики ламоды. Она используется в Андроид, iOS, мобильный сайт и десктоп.

[houligan]

Это собственная разработка, или вы используете сторонее решение? SnowPlow?

[ilsosnin]

Это собственная разработка

[dilix]

По сути ведь все аналитические системы так или иначе принимают нечто вроде

(eventName: String, eventParams: Map<String, String>)

, верно?

Почему не остановится на единственном методе

track(eventName: String, eventParams: Map<String, String>? = null)

, который логирует пачку параметров вместе с ивентом. Именя ивентов — в константы.

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

Т.е. например количество товаров в корзине, примененный промокод и хз что еще — все признак пользователя. Отправлять лишь те параметры вместе с событием, которые релевантны в рамках контекста, а значит уже известны.

Какой кейс у вас, или какие проблемы видите, которые не позволяют упростить аналитику до уровня строки, а не целого объекта?

[Neikist]

какие проблемы видите, которые не позволяют упростить аналитику до уровня строки, а не целого объекта

Классические проблемы динамики. Кто то может забыть в мапу нужные параметры закинуть.