RecommendedBy

[looee1q]

На данный момент в Android SDK существует два одинаковых класса RecommendedBy но в разных пакетах. Один из них нормальный, а второй сделан вообще с применением джава подхода. Полагаю, нужно избаваться от лишнего класса. Вопрос как это сделать? Пометить класс, как Depricated, потому что им в теории могут пользоваться за пределами SDK?

Еще мне непонятен смысл хранения значения RecommendedBy в локальной переменной. Отсутствует концептуальное понимание идеи, которая закладывалась в этот код.

Дело в том, что сохранение значения RecommendedBy сейчас осуществляется в двух местах:

1. При отслеживании любого события мы занулляем переменную, которая храние текущее значение RecommendedBy. Для чего мы это делаем?
2. При отслеживании просмотра истории в переменную RecommendedBy уходит значение с типом RecommendedBy.TYPE.STORIES.

При этом типы RecommendedBy не ограничиваются лишь RecommendedBy.TYPE.STORIES, а включают в себя и другие типы. Однако в SDK отсутствуют места, в которых бы еще происходил вызов UseCase(а), ответственного за присвоение нового значения переменной recommendedBy.
При этом и выдача актуального переменной recommendedBy происходит всего в одном месте в SDK: тут, для формирования запроса при отслеживании действия пользователя.
Соответственно функциональность работы с переменной, которая хранит актуальное значение RecommendedBy практичеси отсвутствует (или нереализована полностью).
Сейчас мне не очень понятна какая логика закладывалась в код, связанный с переменной, хранящей значение RecommendedBy. А именно:

• когда должно обновляться ее значение (при каком действии пользователя)? Полагаю эти действия должны соответствовать тем типам, которые перечислены тут.

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

[TorinAsakura]

И так…
Я правильно понял, что сейчас у нас есть один и тот же класс с разной логикой?

1. Место первое: При отслеживании событий, где текущая логика перезаписывает значение RecommendedBy. Возникает вопрос: для чего это делается и что делать, чтобы избежать путаницы?
2. Место второе: В истории рекомендаций, где RecommendedBy используется для хранения значений с типами (например, TYPE_STORIES).

То есть:

• Нет ясной структуры, куда и как правильно сохранять данные, связанные с рекомендациями
• Текущая реализация размывает ответственность между местами хранения данных и их обработкой

И предлагаешь ты:

• Организовать логику вокруг значений RecommendedBy таким образом, чтобы SDK чётко разделял, где используется каждое значение
• Возможно, вынести логику обновления значений и взаимодействия с ними в отдельный Use Case
• Убедиться, что сохраняемые данные не теряют смемантику, и не происходят внезапные перезаписи

Верно? Я просто в твоей портянке быстро запутался…

[Nelfimov]

мы просто пишем об этом в разделе брикин чейнджс

Что это за раздел такой? И кто туда должен писать?

• в ченйджлоге @Nelfimov подскажет

@looee1q для наших пакетов автоматом генерируется чейнджлог по мержу в мастер. Коммиты парсятся и фомируется чейнджлог. Т.к. мы следуем конвенции коммитов по ангуляру, то чейнджлог создается красивым:

https://github.com/rees46/web/blob/stage/packages/segmentator/CHANGELOG.md

В веб разработке используем https://www.npmjs.com/package/conventional-changelog-cli

Для мобил придется искать аналог

[looee1q]

@Nelfimov

для наших пакетов автоматом генерируется чейнджлог по мержу в мастер.

Что такое пакет в данном контексте? Это какая-то совокупность ПР или коммитов?

[Nelfimov]

мы работаем с монорепозиториями - организация репозитория в котором хранится несколько пакетов/приложений.

У тебя монорепозиторий, поэтому достаточно одного чейнджлога.

[looee1q]

@TorinAsakura В Android SDK нужно тоже ввести файл аналогичный changelog из веба?

[TorinAsakura]

@TorinAsakura В Android SDK нужно тоже ввести файл аналогичный changelog из веба?

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