Комментарии 2
Возможно, я что-то недопонимаю, но, по-моему, задача имеет явно асинхронную природу и не может решаться "в лоб"
Как бы сделал я?
При открытии приложения, его настройки запрашиваются с сервера. В этот момент, пока данные не получены, изменять настройки можно, но их состояние сохраняется только локально, а пользователь может получать уведомление "синхронизация", если изменения критичны для общего функционала.
Во время синхронизации отображается последнее сохранённое ЛОКАЛЬНО состояние настроек приложения и никакие данные настроек на сервер не передаются до их получения.
После получения с сервера и сравнения состояния, конфликты разрешаются, после чего новое состояние отправляется на сервер и только после подтверждения сервером получения новых настроек синхронизация считается законченой и может произойти отправка новых изменений на сервер. До этого момента все изменения только локальны.
Если сервер отказывает в каких-либо изменениях, приложение сообщает об этом и фиксирует этот факт в локальной копии конфигурации
Всё. При таком подходе вообще невозможно возникновение каких-либо проблем подобного рода при вполне доступной возможности изменять настройки приложения.
Если пользователь поменял "флажок" и ушёл с экрана - приложение лишь изменило своё состояние на "запрос синхронизации", сохранив своё состояние локально и ожидая подтверждения изменений данных на сервере.
Учитывая, что приложение по природе своей клиент-серверное и настройки прямо влияют на поведение приложения и передаваемые сервером данные, приоритет синхронизации настроек видится необходимым.
Спасибо за ответ. Согласна, предложенный вариант очень хороший.
В целом примерно такую же схему, как Вы и описали, мы и реализовали в итоге. Юзер видит именно локальную версию настроек (uiState). Новые значения настроек мы можем отправить только после того, как предыдущие запросы были завершены (проверяем в PostProcessor - есть ли необходимость в ещё одном запросе после выполнения текущего). Для проведения этой проверки мы храним закешированное значение - чтобы сравнивать с ним локальное (отображаемое пользователю).
Единственное, что было недоступно в нашей реализации - использовать уведомление "синхронизация". Изначально было требование, чтобы для юзера всё было максимально "незаметно" - никакого прогресса и тд. Хотя, возможно, вариант с синхронизацией мог бы понравиться дизайнеру, но на тот момент мы его не рассматривали.
Охота на toggle: Как простую фичу сделать максимально сложно