Кейс "Как организовать поведение схожее с Инстаграмом"

[matzuk]

Как организовать поведение схожее с Инстаграмом. То есть ты ставишь лайк, и на UI сразу же все отображается. При этом параллельно идет запрос, прочая логика. И в конце концов запрос может провалиться.
iOS кидали в сторону CQRS
http://blog.softmemes.com/2016/11/12/using-cqrs-with-event-sourcing/
https://martinfowler.com/bliki/CQRS.html

Сейчас принимаются идеи, концепции и люди, кто хочет пилить, дабы в дальнейшем не делать двойную работу.

[LionZXY]

Как вариант, сделать background сервис, который будет обрабатывать очередь запросов.
Суть в том, что при нажатии лайк наше событие "нажал лайк" отправляется в специальное хранилище, которое чистит фоновый сервис.
Т.е.

1. Поставили лайк
2. Пробуем его отправить. Если не получается, добавляем в специальную таблицу или в основную таблицу, но с флагом
3. Как только появится интернет, запускаем сервис и он в on start смотрит все лайки, которые не отправились и отправляет.

При выдергивании из бд лайки получаем объединением таблиц (в случае, если это отдельная таблица) или просто выборкой (если это одна таблица)

[electrolobzik]

Мне нравится паттерн "Source Of Truth" (источник правды). Вводится некий новый слой (объект) который изолирует от UI логику асинхронной обработки изменений в объекте модели. В каждый момент времени этот объект отдает текущее актуальное состояние этого объекта. Сразу после того как лайк поставили - он сохраняет информацию об этой заявке на изменение в специальную область модели (бд например). С этого момента он отдает свойства объекта такими, как будто операция уже выполнена до тех пор пока не получит результат запроса (что может теоретически произойти скоро или не скоро в зависимости от бизнес-логики и того допустимо ли ставить лайк без наличия сети). После получения ответа состояние объекта актуализируется и заявка на изменение помечается как выполненная. За всем этим следит этот Source Of Truth. Также может быть очень важно реализовать уведомление подписчиков о том, что источник правды закончил обработку запроса и возможно сама правда изменилась и ее нужно как-то отобразить пользователю. В случае Clean архитектуры мне кажется что источник правды должен быть частью репозитория. Репозиторий такого объекта становится более умным и берет на себя функции источника правды. При этом все остальные слои остаются не тронутыми. (Не считая изменений, которые могут быть а могут не быть для уведомления пользователя о результатах (чаще неудачных) запроса)

[NoNews]

Можно сделать сервис, который будет отвечать за очередь на прикладном уровне OSI и мониторить её в определённое количество секунд.
Т.е., схема будет выглядеть вот так:

1. Нажимаем Like — сразу отображаем поставленный лайк (presentation)
2. Сохраняем изменения в базу, с флагом delivered=falseу данной модели (repository)
3. Пробуем отправить сообщение
4. Если не отправилось — Добавляем PrimaryKey данной модели в отдельную сущность, в которой реализован Set или HashMap (repository)

Задача сервиса:
Раз в n-секунд при наличии интернета и активного соединения, проверять наличие очереди, и если он не пустая и http-запрос сейчас не идёт, делать его.
Если http-запрос успешен — удаляем сообщение из очереди, и сохраняем с флагом delivered=true
Мне кажется, чтобы данный сервис работал только когда приложение в Foreground, т.к. он вполне себе может совмещаться с работой WebSocket-а.

Точка старта — onResume (Т.к. пользователь может принять звонок в момент пользования приложением, после окончания звонка onStart не сработает)

Точка остановки — onStop (Т.к. при выключении экрана срабатывает именно onStop, а не onPause)

Но вообще, вроде как, подобные кейсы (c лайками и подобными событиями) принято гонять на транспортном уровне OSI — с помощью WebSocket, а не по Http.

[adolgiy]

https://proandroiddev.com/offline-apps-its-easier-than-you-think-9ff97701a73f

[scrobot]

@adolgiy предложил пожалуй самое лучшее решение этого кейса из всех, что есть в сети)