-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resource Identifier and URL #93
Comments
Yeah I think this is really important, for example URL can contain dynamic parameters which can break the cache. I think the key can be the URL's absolute string by default but we should be able to customise it somehow to handle our specific use-case. The approach suggested by @RuiAAPeres seems great to handle this. 👍 |
|
Great suggestion for decoupling the key and URL. It is very easy to adjust current code for it. I will handle it soon. |
With the current API we are forced to use the URL as the resource identifier. This won't work in non-trivial scenarios, because we might want the identifier to be different from the URL. For example: creating a thumbnail out of an image.
The image itself as a specific URL (e.g.
http://abc.jpg
). But I want to cache bothhttp://abc.jpg
andhttp://abc.jpg_thumbnail
(this_thumbnail
is generated from the original one). The problem is when I want to fetch the thumbnail from the cache. Because if I passhttp://abc.jpg_thumbnail
and it's not in the cache, it will try to fetchhttp://abc.jpg_thumbnail
which will fail. If I passhttp://abc.jpg
then it will never touch the thumbnail and get the full size one.The fundamental problem is: the cache identifier and the resource's URL are coupled. A quick and easy solution would be to use a struct like this:
We would then pass this struct, instead of the
URL
. For example:to:
Still, for this kind of cases, we can just leave as is. There is no point on passing a
Resource
.Likewise, when the interaction is with the
ImageDownloader
it's fine to use aNSURL
, since theImageDownload
should be responsible only for interactions with the network.Without seeing all the code and assuming the code respects the SOLID principles, only the
KingfisherManager
would have to be updated.The text was updated successfully, but these errors were encountered: