Настройки уведомлений
Связывает продуктовые темы уведомлений, quiet hours и системное разрешение ОС.
Состояния подписки
Иллюстрация по теме
Визуальный ориентир помогает быстрее считать сценарий страницы и не оставлять компонент абстрактным.
Контракт предпочтений
| Inputs | topics, user preferences, OS permission |
|---|---|
| Outputs | subscription commands, explainable UI state |
| Failure mode | permission prompt without value, mismatch with server topics |
| Ownership | UI владеет представлением и recoverable context; финальное бизнес-состояние подтверждает серверный контракт. |
Как хранить выбор
Компонент считается самостоятельной границей только если команда может назвать его входы, выходы и невозможные состояния. Если он требует читать provider-specific поля напрямую или хранит финальный статус операции только локально, граница выбрана слишком поздно.
При изменении контракта сначала обновляется state model и совместимость, затем визуальный слой. Это уменьшает риск ситуации, когда новый UI уже ожидает поле или статус, которого старая версия API не гарантирует.
Связанные разборы
Проверки подписок
- Системный permission prompt появляется после выбора понятной пользователю ценности.
- Topic preference, quiet hours и OS permission хранятся как разные состояния.
- Отзыв permission в настройках ОС корректно отражается после возвращения в приложение.
- Отписка идемпотентна и не зависит от доставки предыдущего push.
- Delivery сбой одного канала не блокирует обновление preferences.
- Экран объясняет, почему уведомление не будет доставлено, если системное разрешение выключено.
Почему настройка пользователя не равна системному разрешению
Preference UI отражает намерение пользователя, а не только технический token push-провайдера. Поэтому подписка, разрешение ОС и фактическая доставка разделены.
При review команда проверяет не название компонента, а его инварианты: какие данные он имеет право считать финальными, что обязан показать при деградации и как возвращается в согласованное состояние после сбоя.
Три уровня, которые нельзя смешивать
У пользователя есть продуктовая подписка на тему, локальные/серверные правила вроде quiet hours и системное разрешение ОС. Все три могут иметь разные состояния. Если OS permission отозван, тема не обязана исчезать: интерфейс может сохранить выбор и объяснить, почему push сейчас не приходит.
Такой контракт упрощает и аналитику — отказ системного permission не маскируется под «пользователь отписался».
Маршрут доставки: настройка → доставка уведомления.
Настройка пользователя, системное разрешение и политика доставки живут на разных слоях
Одна из частых ошибок — свести настройки уведомлений к системному разрешению устройства. На деле продукту нужен отдельный слой предпочтений: темы, команды, quiet hours и типы событий. Если всё это перемешать, пользователь не понимает, почему push пришёл или не пришёл. Практический контекст даёт статья про типы подписок и quiet hours.