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