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
Feature addtional http headers and response #2166
Feature addtional http headers and response #2166
Conversation
4b50eb4
to
5e89565
Compare
1c609b4
to
dc9bcb0
Compare
Well. After some consideration, I think we should break the API and change the return type. This change should at lease in 5.x. The reason why to change this is shown here : Our previous API
So this is adoptable and may not break current usage(Just the API). And I think, return a simple Compared to Kingfisher's same API KingfisherManager.retrieveImage, I think this design is not a bad design and this is not hard to maintain in the future. We should basically add two property, one is All the other properties should be hidden because it rely on the complex internal logic. I think now user can do something awesome feature with it :) |
Can't wait to see this in version 5.x! :) I think PR #2020 can be closed if this is the way to go. |
a93b5ed
to
63f7110
Compare
Codecov Report
@@ Coverage Diff @@
## 5.x #2166 +/- ##
==========================================
+ Coverage 75.51% 80.55% +5.03%
==========================================
Files 42 37 -5
Lines 4121 3625 -496
Branches 353 328 -25
==========================================
- Hits 3112 2920 -192
+ Misses 987 683 -304
Partials 22 22
Continue to review full report at Codecov.
|
b008f33
to
2564a9a
Compare
Current break change (Need change code)SDWebImageManager.h
SDWebImageDownloadToken
|
9c679ad
to
58da331
Compare
I like this one. But I'm not sure whether we should expose |
@skyline75489 You can use a For the download which bridge the cache and downloader together, I don't think this design will be totally change in the future (that will be a really huge change). So a request to load image must contains two process: This design is adopted from Kingfisher too. I think this design is not a bad design. |
58da331
to
1f5d09b
Compare
@skyline75489 I seperate the But that And also, some user ask to allow custom scale factor because of that our |
1f5d09b
to
bfd8189
Compare
bfd8189
to
b83f8ac
Compare
b83f8ac
to
84f6cae
Compare
…ration and download token to user
84f6cae
to
de63c77
Compare
1681346
to
0fa6e88
Compare
Maybe this feature we need more time to allow extensibility. Currently it can only apply the HTTP Headers. However, for We can introduc a more common usage like |
@BlueVirusX @skyline75489 This PR was replaced by #2261 . Which provide a more common use case and abstract implementation to keep extensibility |
New Pull Request Checklist
I have read and understood the CONTRIBUTING guide
I have read the Documentation
I have searched for a similar pull request in the project and found none
I have updated this branch with the latest master to avoid conflicts (via merge from master or rebase)
I have added the required tests to prove the fix/feature I am adding
I have updated the documentation (if necessary)
I have run the tests and they pass
I have run the lint and it passes (
pod lib lint
)This merge request fixes / reffers to the following issues: #2020
Pull Request Description
This PR introduce the feature to provide custom HTTP addtional headers for each UIView request, and grab the
NSURLResponse
from the download operation to the top entry of our lib. It based on thecontext
arg.