Skip to content

Latest commit

 

History

History
80 lines (49 loc) · 5.99 KB

File metadata and controls

80 lines (49 loc) · 5.99 KB

Задача 5 | Список спецпредложений – логика, обработка данных и подготовка отображения

⬅️ назад

ТЗ

Есть класс SpecialOfferDataToUiModelMapper, который предназначен для перевода доменных данных о списке офферов (List<OfferInfo>) в данные для UI списка спецпредложений (List<SpecialOfferUiItem>).

На вход метод класса SpecialOfferDataToUiModelMapper получает список списке офферов (List<OfferInfo>) и данные о пользователе UserInfo.

На выходе вы должны вернуть отфильтрованный список офферов List<SpecialOfferUiItem>

Нужно отфильтровать офферы по следующему правилу;

  1. Если у оффера в поле restrictions пустой список, то оффер оставляем (при выполнении остальных условии)
  2. Если restrictions содержит for_bundles, то оффер оставляем если код подписки пользователя содержится в массиве bundles_ids (подробности описаны ниже)
  3. Офферы со статусом "HIDDEN" не показываем
  4. Офферы с типом "CREDIT" показываем только в статусах "NEW","OLD"
  5. Офферы с типом "PERSONAL" показываем только, если restrictions пустой

Алгоритм определения доступен ли оффер для пользователя

Определяем какая подписка у пользователя

Нужно получить список всех подписок (с помощью метода getBundles() у BundlesRepository) и используя информацию о пользователе взять полную информацию о подписке с конкретным кодом Если подписка не нашлась – все хорошо, так как подписка необязательна (у пользователя может не быть подписки).

Проверяем для каких подписок доступен оффер

Если у спецпредложения есть ограничения по подписке (список в поле restrictions не пустой), то необходимо проверить, что оффер доступен для текущей подписки пользователя (то есть если в restrictions/for_bundles в массиве есть код подписки пользователя значит этот оффер доступен для текущей подписки пользователя). Если подписка пользователя и ограничения оффера по подпискам совпали, то нужно использовать данные о текущей подписке (в поле bundle передаем информацию о подписке пользователя)

Если подписка пользователя и ограничения оффера по подпискам НЕ совпали, то данный оффер НЕ доступен для пользователя => этот оффер не нужно возвращать в списке List<SpecialOfferUiItem>

Если оффер доступен без подписки (список в поле restrictions пустой), то в поле bundle необходимо положить значение null

Формат входных данных

На вход в SpecialOfferDataToUiModelMapper поступает List<OfferInfo> и UserInfo

Формат выходных данных

Выходные данные в формате List<SpecialOfferUiItem> (отфильтрованный и обработанный список), где SpecialOfferUiItem это

data class SpecialOfferUiItem( val id: String, val title: String, val description: String, val bonusValue: String, val bgColorHex: String, val imageResId: Int, val isFavorite: Boolean, val bundle: BundleInfo, )

id = offerInfo.id,

title = offerInfo.supplierName,

description = offerInfo.shortDescription,

bonusValue При отображении подписки в оффере необходимо учитывать значение newValue – это то число бонусов, которое доступно только подписчикам. Например, если в bonus.value лежит 5, а в restrictions/for_bundles.newValue 7, то необходимо отображать именно значение 7 для bonusValue

В иных случаях bonusValue = offerInfo.bonuses.value

bonusValue формируется следующем образом: "n%" (для типа cashback) и "n баллов" (для типа special_points), n - какое-то число

imageResId = offerInfo.offerImage

bgColorHex = offerInfo.supplierBaseColor

isFavorite = Значение этого поля нужно получить с помощью метода favoritesRepository

bundle = Информация о подписке пользователя (если оффер доступен для текущей подписки пользователя) или null (если оффер доступен любому пользователю без подписки)

Ожидаемое решение

Необходимо реализовать логику внутри класса SpecialOfferDataToUiModelMapper, который отвечает за перевод доменных данных в данные для UI списка "Специальных предложений"