Q
Задался таким вопросом т.к. со временем этих аргументов там может быть кучу.
lastModifyEnable и т..д.
lastModifyEnable и т..д.
тогда сделай две fun: locale, remote )
Size: a a a
2020 May 06
НЭ
это только вариант как я мог обойти возврат старой, закэшированной инфы, а так да, фигово будет если неудачный запрос..
Потому invalidate лучше, чем clear. Ты просто сообщаешь, что данные устарели и более ничего не делаешь, а при повторном запросе, если данные устарели, то пробуешь запросить новые и перезаписать их.
D
Зачем вообще его очищать ? А если запрос закончился неудачно, показать пустоту ?
обычно в таких случаях показывается Snackbar с ошибкой или нечто подобное. т.к. pullToRefresh предполагает, что список с данными у нас уже отображается, просто они могут быть не слишком актуальны. но всё конечно зависит от случая и очищать кэш в таком случае -- такое, да)
Q
обычно в таких случаях показывается Snackbar с ошибкой или нечто подобное. т.к. pullToRefresh предполагает, что список с данными у нас уже отображается, просто они могут быть не слишком актуальны. но всё конечно зависит от случая и очищать кэш в таком случае -- такое, да)
я, кажется, об этом и сказал
D
я сослался на конкретное сообщение, где ты при неудачном запросе говоришь о показе пустоты
I
Все ребята, спасибо. Пойду, наконец, работать, а не думать как это сделать по феншую )
Y
Добрый вечер! Возник интересный кейс. У меня приложение условно разделено на три слоя, ui, domain, data. ui и data не знают друг о друге и общаются через domain. В качестве асинхронной составляющей корутины. Сам кейс в том, что на слое даты есть Firebase и у него есть Колбэк об обновлении данных. Как я могу прикидывать эти данные с data на ui при этом не прокидывая такой колбэк через весь проект?
Очень просто. Я так обертывал авторизацию по телефону и смс коду.
Имхо это для Котлин чата больше подходит
https://medium.com/@elizarov/callbacks-and-kotlin-flows-2b53aa2525cf
Имхо это для Котлин чата больше подходит
https://medium.com/@elizarov/callbacks-and-kotlin-flows-2b53aa2525cf
Q
вот я голову ломаю...у меня парсинг...думаю где бы реализовать этот самый парсинг: в DataSource или в Mapper... Т.е. чтобы DataSource возвращал просто String и потом репозиторий его трансформировал в объект бизнеса...
Q
нет, думаю логично будет парсить в DataSource
НЭ
вот я голову ломаю...у меня парсинг...думаю где бы реализовать этот самый парсинг: в DataSource или в Mapper... Т.е. чтобы DataSource возвращал просто String и потом репозиторий его трансформировал в объект бизнеса...
DataSource - курьер. Сходил за данными и все. Repo уже с ними может поработать, но лучше вынести маппинг в маппер. Так ты сможешь в Repo инжектить эти мапперы и можно будет проще все это дело замокать при необходимости. Ну и отдельные мапперы лучше для покрытия юнитами.
Q
DataSource - курьер. Сходил за данными и все. Repo уже с ними может поработать, но лучше вынести маппинг в маппер. Так ты сможешь в Repo инжектить эти мапперы и можно будет проще все это дело замокать при необходимости. Ну и отдельные мапперы лучше для покрытия юнитами.
Дело в том, что DataSource имеет один интерфейс для всех
НЭ
Дело в том, что DataSource имеет один интерфейс для всех
А какая у вас структура?
Q
Например тот же файловый кеш
Q
Хранится в виде Json в файле
Q
interface DataSource {
suspend fun getData(): MyEntity
}
suspend fun getData(): MyEntity
}
Q
Это образно. Если из сети String и из файла String... глупо, как то...
НЭ
А DataSource кто вызывает? сразу domain слой или всеже repository?
Q
Репозиторий
Q
Просто если через неделю появится api на удаленном сервере, то String не катируется...
Q
Я оставил репозиторий только ответственным за выбор источника