Skip to content

MOBILE-635: Drop an in-app whose frequency or display condition cannot be read - #840

Merged
Vailence merged 1 commit into
developfrom
feature/MOBILE-635-unknown-display-conditions
Nov 5, 2026
Merged

Vailence merged 1 commit into
developfrom
feature/MOBILE-635-unknown-display-conditions

Conversation

@Vailence

@Vailence Vailence commented Nov 5, 2026 •

Copy link
Copy Markdown
Collaborator

https://tracker.yandex.ru/MOBILE-635

Нечитаемые frequency и displayConditions теперь выбрасывают только свой инапп, как на iOS (MOBILE-499). Отсутствующее поле и null дают прежний дефолт: once/lifetime и «без условий».

  • InAppDtoBlank хранит сырые frequency и displayConditions как JsonElement?, чтобы отличать «поля нет» от «не прочитано»; NullSafeJsonObjectDeserializer удалён.
  • MobileConfigRepositoryImpl.getInApps разбирает поля и отбрасывает инапп через mapNotNull, лог — logParseFailure.
  • "frequency": null и не-объект больше не роняют разбор всего конфига.
  • InAppRestrictionFieldsTest: 21 кейс, в каждом проверяется, что соседний инапп выжил.

…t be read

A missing or null value still means the default: once per lifetime for
frequency, no conditions for displayConditions. Anything else the SDK
cannot read now drops only that in-app, the same way iOS does.

Before, an unknown or malformed displayConditions read as no conditions,
so direct-call story content showed by itself on start. An unknown
frequency read as once per lifetime, and a null or non-object frequency
failed the whole inapps block.
@Vailence
Vailence merged commit f23467b into develop Nov 5, 2026
@Vailence
Vailence deleted the feature/MOBILE-635-unknown-display-conditions branch November 5, 2026 18:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants