Q
Зачем очищать кеш перед запросом ? И почему репозиторий не сингл ?
Size: a a a
2020 May 06
I
Зачем очищать кеш перед запросом ? И почему репозиторий не сингл ?
1, 2 ,3 это варианты решения, а не как сейчас реализовано.
Вариант с предварительной очисткой кэша, что бы репозиторий посмотрел кэш увидел уто там пусто и пошел в сеть..
Не синглетон - это про вариант 3? это один из вариантов, разных репозиториев под разные кейсы..
Вариант с предварительной очисткой кэша, что бы репозиторий посмотрел кэш увидел уто там пусто и пошел в сеть..
Не синглетон - это про вариант 3? это один из вариантов, разных репозиториев под разные кейсы..
K
Не сингл в плане не
но это не суть важно
fun getTree(ignoreCache: Boolean): Single<List<Tree>>
но это не суть важно
НЭ
Привет ребята.
Такой вопрос, есть репозиторий
Но есть такой кейс: при pulltorefresh, данные в любом случае должнны тянутся с сервера и обновляться в кэше(DB).
Варианты решения:
1) метод getTree репозитория принимает параметр
3) реализация репозитория инжектится в момент запроса (при каждом запросе создаем объект репозитория, первый может взять из кэша, а второй берет только с сервера и кэширует в DB)
4) ...?
- Если выбрать первый вариант, то возникает вопрос, нормально ли вообще, что клиент знает о наличии кэша и вот таким образом все это разруливает?..
- Если выбрать второй вариант, то кто должен заниматься очисткой? - где этот метод clearTree()? Ну допускаем только вариант, что в репозитории т.к. по другому нет доступа к слою данных. Допустили этот вариант, а что будет есть у нас появится какой то репозиторий который вообще не умеет кэшировать и метод clearTree() никак не реализовать, рузультат выполнения всегда false(условно)?
- Если третий вариант, то вроде бы гуд, или нет?
В итоге, как вы реализуете такой кейс?
Такой вопрос, есть репозиторий
interface TreeRepository {
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 цепочку например.
НЭ
Причем репозиторию не обязательно реализовывать invalidateCache, если у вас к примеру пока не реализован кэш, а данные всегда свежие запрашиваются.
НЭ
А пушнуть данные в туже цепочку можно через repeatWhen, если интерактор будет возвращать Observable.
Q
Зачем вообще его очищать ? А если запрос закончился неудачно, показать пустоту ?
Q
Или хоть и устаревшие, но всё же данные из бд, но с оговоркой
НЭ
Зачем вообще его очищать ? А если запрос закончился неудачно, показать пустоту ?
Необязательно в invalidateCache очищать. Можно их сделать протухшими и при удачном запросе перезаписать, а при неудачном достать из кэша и сообщить об ошибке
Q
Вот и я об этом
Q
Я, как правило, указываю время жизни кеша
Q
isExpired ? всё, идем в сеть
НЭ
Я, как правило, указываю время жизни кеша
Ну это норм, только не решает вопроса прямого запроса от пользователя
I
Pulltorefresh это действие пользователя, которое является логикой работы приложения. Событие прокидывается как "pulltorefresh" до domain слоя в interactor например. Тот в свою очередь уже может знать о кэше, т.к. данный кейс это часть логики. Сделать invalidateCache (clearTree), перезапросить данные и пушнуть их в нужную rx цепочку например.
Ок, я понял так,
fun getTree(invalidateCache: Boolean)нормальный вариант.. В репозитории
Q
Ну это норм, только не решает вопроса прямого запроса от пользователя
обычный аргумент refresh: Boolean
D
Привет ребята.
Такой вопрос, есть репозиторий
Но есть такой кейс: при pulltorefresh, данные в любом случае должнны тянутся с сервера и обновляться в кэше(DB).
Варианты решения:
1) метод getTree репозитория принимает параметр
3) реализация репозитория инжектится в момент запроса (при каждом запросе создаем объект репозитория, первый может взять из кэша, а второй берет только с сервера и кэширует в DB)
4) ...?
- Если выбрать первый вариант, то возникает вопрос, нормально ли вообще, что клиент знает о наличии кэша и вот таким образом все это разруливает?..
- Если выбрать второй вариант, то кто должен заниматься очисткой? - где этот метод clearTree()? Ну допускаем только вариант, что в репозитории т.к. по другому нет доступа к слою данных. Допустили этот вариант, а что будет есть у нас появится какой то репозиторий который вообще не умеет кэшировать и метод clearTree() никак не реализовать, рузультат выполнения всегда false(условно)?
- Если третий вариант, то вроде бы гуд, или нет?
В итоге, как вы реализуете такой кейс?
Такой вопрос, есть репозиторий
interface TreeRepository {
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(условно)?
- Если третий вариант, то вроде бы гуд, или нет?
В итоге, как вы реализуете такой кейс?
всю дорогу использую в подобных случаях первый вариант и не вижу проблем. ну знает клиент о кэше и знает 🤷♂ зачем оверинженирить на ровном месте и потом приседать
НЭ
Ок, я понял так,
fun getTree(invalidateCache: Boolean)нормальный вариант.. В репозитории
Норм, но так ты не сможешь сделать repeatWhen в интеракторе. Лучше 2 метода.
НЭ
Ну я бы сделал 2 метода))
I
всю дорогу использую в подобных случаях первый вариант и не вижу проблем. ну знает клиент о кэше и знает 🤷♂ зачем оверинженирить на ровном месте и потом приседать
Задался таким вопросом т.к. со временем этих аргументов там может быть кучу.
lastModifyEnable и т..д.
lastModifyEnable и т..д.
I
Зачем вообще его очищать ? А если запрос закончился неудачно, показать пустоту ?
это только вариант как я мог обойти возврат старой, закэшированной инфы, а так да, фигово будет если неудачный запрос..