Очистить кэш SDWebImage

Question

Я работаю над приложением для iPhone, в котором есть лента новостей. Эта новостная лента взята из написанного мной веб-сервиса JSON (в настоящее время я использую MAMP на моем ноутбуке).

В любом случае, я использую базу данных MySQL для хранения ссылок на мои изображения, которые хранятся в файловой системе apache.

Я храню их очень особым образом, и вот как я их храню:

Полные изображения: ng_(postid)_(seqid)
Превью: tng_(postid)_(seqid)

PostID - это уникальный идентификатор, назначаемый каждому сообщению новостей.
SeqID - это идентификатор, который уникален только для фотографий этого сообщения.

Я, наверное, не очень ясно выразился ... пример:

Файлы изображений в первом посте могут выглядеть следующим образом

ng_1_1.jpg
ng_1_2.png
ng_1_3.jpg

Файлы изображений для второго поста могут выглядеть следующим образом

ng_2_1.jpg
ng_2_2.png
ng_2_3.gif

До сих пор это работало отлично, но я пытался понять, что произойдет, если я удалю сообщение и создаю его заново?

Допустим, у нас есть пост «Старая почта», в котором есть 2 изображения с позицией 7.

Это изображения могут выглядеть так:

ng_7_1.jpg
ng_7_2.jpg

Допустим, мы удалили эту запись, а затем создали новую, которая имеет три изображения и называется «Новая запись».

Это изображения будут выглядеть так:

ng_7_1.jpg
ng_7_2.jpg
ng_7_3.jpg

Теперь возникает проблема ... Если устройство просмотрело старый пост, который был удален, а затем просмотрело этот новый пост, они увидят первые два изображения как изображения со СТАРОГО ПОСТА. Не новые.

Почему? SDWebImage считает, что URL-адрес идентичен, и поэтому решает извлечь кэшированное изображение с диска. Он даже не отображает кэшированную версию, а затем проверяет, обновлено ли изображение.

Итак, я разработал два возможных решения этой проблемы:

1. Каким-то образом получить SDWebImage, чтобы проверить изображение в сети, после отображения кэшированной версии
2. Передайте ключ в моем JSON, чтобы сказать моему приложению, чтобы он стер кеш SDWebImage (при необходимости)

Итак, мой вопрос: как бы вы удалили кеш SDWebImage или заставили его проверить сервер после отображения кэшированной версии?

Answer 1

Я думаю, что ваши значения PostID не уникальны в вашей системе, и это вызывает у вас проблемы.Если бы у вас были уникальные значения PostID, было бы невозможно удалить сообщение с заданным идентификатором и присвоить это значение идентификатору новому сообщению ...
По моему мнению, PostID не должен использоваться повторно - можете ли вы представить себе клерка, удаляющего конкретное сообщение?заказать в своей системе, создать новый со старым идентификатором и однажды позвонить клиенту, который предоставит свой идентификатор заказа, который теперь перезаписан в системе?

Другое дело, что вам никогда не следует удалять кэшированные изображения на стороне клиента - будьте удобны для пользователя, сохраняйте полосу пропускания и планы данных пользователей (проверьте эту ссылку , почему это важно).Однако вы можете указать cacheMaxCacheAge для SDWebImage, чтобы избавиться от старых, неиспользуемых изображений.Вы также можете удалить определенные изображения, используя removeImageForKey:, когда, например, пользователь решает удалить конкретное сообщение на своем устройстве.

Наконец, описываемый вами случай больше относится к обновлению определенного сообщения, поэтому сообщения могут получитьнапример, другой набор изображений.В этом сценарии самое простое, что вы можете сделать, - это использовать уникальные идентификаторы изображений, поэтому при загрузке публикации будут загружаться новые изображения (старые будут удалены, когда кэш достигнет своего максимального возраста - ищите cacheMaxCacheAge).В качестве альтернативы, вы можете внедрить своего рода механизм синхронизации в вашей DB / JSON (например, на основе временных меток: если сообщение загружено и имеет более новую временную отметку, чем сообщение, сохраненное в кеше приложения, вы удаляете старые ресурсы и загружаете новые изображения, тексти т. д. Если временные метки равны, вы хорошо справляетесь с уже загруженными данными.

В расширенном решении будут использоваться RestKit и Core Data, которые позволят пользователям просматривать ваши сообщения в автономном режиме иобновлять контент (изображения, текст) при изменении вашего веб-ресурса (JSON).

Какое послание ... Надеюсь, мои комментарии вам пригодятся:)