Qt. Синхронизация состояния моделей на клиенте. Как?
Привет. Вопрос расскажу на примере.
Есть один класс модели, допустим NewsListModel.
В мобильном или десктопном приложении создаётся два объекта данной модели - один экземпляр для запроса списка всех новостей с бекенда, второй - для запроса статей в профиле пользователя, то есть принадлежащих текущему авторизованному пользователю.
Отображается это всё соответственно на двух разных экранах, вьюшки никак не пересекаются друг с другом да и модели собственно тоже. Хотя модели и ссылаются на один и тот же источник данных.
Каждую новость например можно лайкнуть.
Наш текущий пользователь находясь в своём профиле лайкает некоторую новость, разумеется информация об этом записывается в модель и например синхронизируется с сервером.
Проблема заключается в том, что когда пользователь перейдёт на страницу просмотра всех новостей, где используется второй объект того же класса модели, информация в данном окне у пользователя будет устаревшей. То есть соответствующая новость в списке будет не лайкнута.
У меня есть пара мыслей как можно попробовать решить данную проблему, но хотелось бы сначала узнать, а не существует ли уже готового решения? Может и не из области Qt, проблема то общего харакетра...
А если так — модель одна, ее напрямую используем для запроса всех новостей с backend, а список статей в профиле выдаем через фильтрацию той же модели посредством QAbstractProxyModel?
Я думал о том, что можно в одной большой модели делать подряд несколько запросов к API для получения всех необходимых данных, а затем - показывать в разных частях приложения данные отфильтрованные локально на основании QAbstractProxyModel.
Думаешь, куча запросов - это хорошее решение? Да и обновлять в случае чего придётся так же - через несколько запросов. Кроме того, нужно будет городить логику, при которой на клиенте я должен будут исключить повторение Item-ов в модели и делать порционную очистку/пополнение такой модели данными...
Ну в данном случае, я вижу ровно четыре запроса в начале — получение скажем десяти последних общих статей и получение десяти последних персональных. Это грузится в модель.
Потом получение последних ста общих id и получение последних ста персональных id — это грузится в кеш менеджера подгрузок. Менеджер подгрузок когда его скажем попросят 10 следующих общих статей возьмет список id, проверит по QMap _loaded; какие уже есть, выкинет лишние и запросит список у сервера. Подписаться на очистку, снять галочки в _loaded и готово.
В общем сложной логики и кучи запросов я тут не вижу)