Ответ 1
Ваша проблема звучит не так, как она связана с RecyclerView.Adapter - и на самом деле вы не должны пытаться решить ее в своем Adapter: ответственность адаптера должна выступать в качестве моста (или "адаптера" );-)) между вашими данными и компонентом представления. Предоставление ему большей ответственности превратило бы его во что-то, что не является взаимозаменяемым с другими реализациями Adapter (вы этого не хотите!).
Вероятно, вы должны найти чистый способ абстрагировать сохранение данных. Кэш-память в памяти должна входить в эту абстракцию. Вы упомянули шаблон репозитория, это будет хороший выбор ИМХО.
Ваша архитектура должна выглядеть примерно так:
adapter -> repository -> |-> cache
|-> database
Репозиторий объединяет логику доступа к данным (ваш DAO) и обработку кеша (ваш CacheManager). Репозиторий всегда будет сначала проверять кеш, а затем извлекать данные из базы данных. Он также обновляет кеш, если извлекаются не кэшированные данные. Кроме того, он регистрирует обновления в базе данных. Как только база данных уведомляет об измененных данных, репозиторий имеет возможность обновить кеш и/или распространить уведомление на представление. Важная часть заключается в том, что интерфейс репозитория скрывает всю эту логику; он предлагает только доступ к данным.
Затем вам нужно найти способ заставить ваш адаптер работать с вашим репозиторием. Я бы предложил Android Loader. Благодаря этому вы получаете бесплатную асинхронную загрузку и правильную обработку жизненного цикла. Также это красиво отделяет адаптер и репозиторий.
Если вам нужно вдохновение в отношении применения шаблона репозитория, посмотрите googlesamples/android-architecture Github. ветвь чистой архитектуры может вам пригодиться.
На стороне примечания: попробуйте найти реальные (уникальные) ключи ваших данных. Использование позиции в списке данных обычно является плохой идеей и в зависимости от структуры ваших данных приведет к появлению странных побочных эффектов в представлении.
