с сервака (их много, поэтому частями), и закешировать их в локальной БД.
Для этого есть простая логика:
1. Планируем джоб загрузчика данных
2. Проверяем в загрузчике данные в локальной БД (кол-во или последний ИД)
3. Запрашиваем с сервака пороцию данных (например 20 элементов), начиная с последней позиции или последнего ИД в базе.
4. Получаем данные, пишем в БД
5. Если сервер ответил, что есть еще данные для загрузки, планируем джоб на следующую порцию
6. и т.д.
С джобами все ясно - это платформозависимый слой, можно сказать слой "представления-отображения" для андроида.
Но вот не пойму как лучше попилить остальную логику между бизнес-слоем и слоем репозитория/гейтвея?
С одной стороны репозиторий должен абстрагировать нас от сети/БД (то есть юзкейс не должен о них знать), а с другой получается, что ответственность за выборку следующей порции явно должна лежать на юзкейсе (то есть он должен знать о том, какие данные закешированы, и какую именно порцию грузить)
Вот такая вот головоломка на нетрезвый ум =)
Всё бухие. Ты не вовремя
Это головоломка, чтобы проверить мышление на нетрезвую голову 😉
Обсуждают сегодня