Sdwebimage: what are replaced methods for cachedImageExistsForURL: and diskImageExistsForURL: in version 4.0?

Created on 1 Jun 2017  路  9Comments  路  Source: SDWebImage/SDWebImage

New Issue Checklist

Issue Info

Info | Value |
-------------------------|-------------------------------------|
Platform Name | e.g. ios / tvos
Platform Version | e.g. 8.0
SDWebImage Version | e.g. 3.7.6
Integration Method | e.g. carthage / cocoapods / manually
Xcode Version | e.g. Xcode 7.3
Repro rate | e.g. all the time (100%) / sometimes x% / only once
Repro with our demo prj | e.g. does it happen with our demo project?
Demo project link | e.g. link to a demo project that highlights the issue

Issue Description and Steps

Please fill in the detailed description of the issue (full output of any stack trace, compiler error, ...) and the steps to reproduce the issue.

Most helpful comment

This return type change is the main feature of 5.0. Now, the manager does not knwo what cache class is. You can custom you own cache other than SDImageCache class, like YYCache, MMKV, any of them. So this is why it's a protocol but not a class type.

See release log: https://github.com/SDWebImage/SDWebImage/releases/tag/5.0.0
Wiki: https://github.com/SDWebImage/SDWebImage/wiki/Advanced-Usage#custom-cache-50

For your case, if you don't use any of custom cache implementation, and you don't use custom manager with multiple caches (See 5.0 feature of multiple caches), you can just using SDImageCache.shared to call the method, it's the same.

For other cases, you can just grab the manager.imageCache and use the isKindOfClass check to ensure it's a SDImageCache instance.

All 9 comments

@singhjagjot1992 I might be missing something, but this is a question you can answer very quickly by just looking at the code or reading the docs (the removal of those methods was added to the Changelog and the release notes section).

Look at cachedImageExistsForURL:completion: and diskImageExistsForURL:completion:

@bpoplauschi, I know this issue was closed long ago, but I'm just migrating to 4.3.3 and I'm looking for best practices for checking if an image is in the cache synchronously. I have many places in my code where I just want to verify if an image has been downloaded, but modifying the code to do that asynchronously will require a large amount of re-architecting.

So far the only alternative I can see is using imageFromDiskCacheForKey: to actually load the whole image into memory and see if that was successful. That seems very inefficient.

Thank you for any guidance you can provide!

I suggest diskImageDataExistsWithKey: (the sync one)

Thanks! I didn't see that in the docs.

Hi @bpoplauschi or @dreampiggy. I'm back! I'm now upgrading SDWebImage to v5.0.5 and it looks like diskImageDataExistsWithKey: has either been removed or has been made private. Is that the case? If so, is there another way to synchronously check if an image has been cached?

I'm trying, wherever possible, to use the new asynchronous methods, but I have one situation that is very time-sensitive. I'm showing an image to the user on a splash screen while content loads behind it and I don't have time to wait for the image to download if it hasn't already been cached...I have a different view that I will show to them of no images are available.

Any guidance on the best way to approach that situation?

Thanks!

EDIT: I think I've found the source of some of my confusion. I had been using [[[SDWebImageManager sharedManager] imageCache] diskImageDataExistsWithKey:sponsorLogoCacheKey]; to check if the logo exists in the cache, but now it seems that [[SDWebImageManager sharedManager] imageCache] returns an object of type SDImageCacheDefine, which doesn't have the disImageDataExistsWithKey: method. Not sure yet how to access the actual SDImageCache object that exists behind that.

Can I use [SDImageCache sharedImageCache] to access the same cache as above, but directly (without going through SDWebImageManager)?

Why not just using the SDImageCacheProtocol method ? That do what you need.
See documentation: https://sdwebimage.github.io/Protocols/SDImageCache.html#/c:objc(pl)SDImageCache(im)containsImageForKey:cacheType:completion:

And, the diskImageDataExistsWithKey: is not private. I assume you have something install issue or header include issue.
See: https://sdwebimage.github.io/Classes/SDImageCache.html#/c:objc(cs)SDImageCache(im)diskImageDataExistsWithKey:

This return type change is the main feature of 5.0. Now, the manager does not knwo what cache class is. You can custom you own cache other than SDImageCache class, like YYCache, MMKV, any of them. So this is why it's a protocol but not a class type.

See release log: https://github.com/SDWebImage/SDWebImage/releases/tag/5.0.0
Wiki: https://github.com/SDWebImage/SDWebImage/wiki/Advanced-Usage#custom-cache-50

For your case, if you don't use any of custom cache implementation, and you don't use custom manager with multiple caches (See 5.0 feature of multiple caches), you can just using SDImageCache.shared to call the method, it's the same.

For other cases, you can just grab the manager.imageCache and use the isKindOfClass check to ensure it's a SDImageCache instance.

@dreampiggy, thanks for the great answers!

Using containsImageForKey:cacheType:completion: would have required re-architechting some portions of my app to allow for an asynchronous check. Accessing the cache using SDImageCache.shared ended up working just fine.

Thanks again!

Was this page helpful?
0 / 5 - 0 ratings