fun getTree(): Observable<List<Tree>>
}
Данные идут с сервера и кэшируются в DB. Если есть кэш то репозиторий дает данные из кэша, а если данных нет то лезет в сеть.
Но есть такой кейс: при pulltorefresh, данные в любом случае должнны тянутся с сервера и обновляться в кэше(DB).
Варианты решения:
1) метод getTree репозитория принимает параметр
fun getTree(ignoreCache: Boolean): Observable<List<Tree>>
2) перед выполнением запроса getTree() выполняем очистку кэша clearTree()
3) реализация репозитория инжектится в момент запроса (при каждом запросе создаем объект репозитория, первый может взять из кэша, а второй берет только с сервера и кэширует в DB)
4) ...?
- Если выбрать первый вариант, то возникает вопрос, нормально ли вообще, что клиент знает о наличии кэша и вот таким образом все это разруливает?..
- Если выбрать второй вариант, то кто должен заниматься очисткой? - где этот метод clearTree()? Ну допускаем только вариант, что в репозитории т.к. по другому нет доступа к слою данных. Допустили этот вариант, а что будет есть у нас появится какой то репозиторий который вообще не умеет кэшировать и метод clearTree() никак не реализовать, рузультат выполнения всегда false(условно)?
- Если третий вариант, то вроде бы гуд, или нет?
В итоге, как вы реализуете такой кейс?
Pulltorefresh это действие пользователя, которое является логикой работы приложения. Событие прокидывается как "pulltorefresh" до domain слоя в interactor например. Тот в свою очередь уже может знать о кэше, т.к. данный кейс это часть логики. Сделать invalidateCache (clearTree), перезапросить данные и пушнуть их в нужную rx цепочку например.
всю дорогу использую в подобных случаях первый вариант и не вижу проблем. ну знает клиент о кэше и знает 🤷♂ зачем оверинженирить на ровном месте и потом приседать
Обсуждают сегодня