Как организовано кэширование в клиентах соцсетей?

#ios #android #java #objective_c #кэширование

Всем добрый вечер!
В процессе написания приложения возникла необходимость кэширования определенной информации
на устройстве, но для меня пока не понятен алгоритм такого кэширования!
То есть, например в приложении клиент ВК на андроид в режиме оффлайн я могу просмотреть
довольно большое кол-во заранее просмотренной информации, например переписку, собственный
профиль, некоторые фото, список друзей и т.д.. 
Я пытаюсь написать подобный клиент и меня интересует как это лучше организовать,
может существуют готовые рекомендации или набор определенных правил, алгоритмов.
Буду рад вашей помощи!
Заранее всем большое спасибо!    

Ответы

Ответ 1

По науке делается так:

Пишем сервис/фоновый поток который берет из сервера по расписанию необходимые данные
и складывает их в SQLite базу. Этот же поток/сервис должен следить за размером кэша,
авторизацией и проч. вещами. Наружу он практически не должен высовываться - тихо сидеть
в фоне и подгружать данные по мере необходимости
Над SQLite базой организуем ContentProvider выдающий наружу интересующие нас поля
Сверху ContentProvider'а нахлобучиваем CursorAdapter, который в свою очередь отображает
данные на кастомный ListView
Если сделать ListView по уму то можно его "научить" операциям pull-to-refresh - то
есть при достижении донышка "дергать" фоновый поток и подгружать старые записи.


Ответ 2

В SQLite скидывать закэшированные данные (ну или просто в директорию складывать какую-нибудь),
в случае отсутствия сети показывать эти данные.
И даже, если есть сеть, можно показывать эти данные, если они валидны. 
К примеру, сделать, чтобы запросы возвращали помимо данных ещё и хэш данных, чтобы
каждый раз всю ленту не грузить в случае, если хэш не изменился.


Ответ 3

Кроме метода, описанного выше, иногда применяют прямую сериализацию в файл: объект
сохраняется в файл в формате json или xml, либо вообще используется бинарная сериализация.
Последняя - самая быстрая (потому что не требует парсинга), но требует немало хлопот,
если язык не поддерживает сериализацию объекта "как есть". В таком случае приходится
делать описание необходимых свойств объекта и по очереди их складывать в файл, чтобы
потом их ровно в таком же порядке прочитать в те же самые свойства, либо выдумывать
собственные костыли по сохранению справочников и подобных сложных типов.
Также обычно приложению предоставляется механизм для сохранения данных (если делаете
Телеграм - вам нужен IsolatedStorage), но он зачастую оказывается медленнее - где-то
видел статью, что твиттер на виндофоне в результате плюнул на все и перешел на бинарную
сериализацию, потому что все остальное по скорости было сопоставимо с прямым интернет-запросом.
Там же писали, что использовали максимальное дробление данных по файлам, что позволяло
подгружать данные только в том случае, если они нужны, что уменьшало оверхеды.
И последнее касательно твиттера - эта штука своим кэшем съела у меня 70мб памяти
на андроиде. Если делаете реальный кеш - не забывайте удалять устаревшие записи.