-
Notifications
You must be signed in to change notification settings - Fork 123
Add head
property to FileDownloadDelegate
's Progress
/Response
struct
#811
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
Add head
property to FileDownloadDelegate
's Progress
/Response
struct
#811
Conversation
summoning @Lukasa and @dnadoba since this was discussed previously here: #680 (comment) |
Hi @gregcotten, thanks for opening this and sorry for the slow time to review, it's been a busy week. I'll take a look now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, left a note in the diff. Can we also add at least one unit test?
it will never be seen by the library user with this data since `didReceiveHead(...)` is called before we report progress or finalize
OK @Lukasa I, at my own risk, have diverged from your suggestion as I think it's really important that the I've also added its use to existing unit tests, but can make a unique unit test if you have any suggestions. |
Needless to say this should be a squash merge if accepted :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very minor nits here but this is looking good. I'll kick off CI for some more info there as well.
Looks like the formatter wants a few tweaks from you. |
Done! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome, I really like this.
I needed a way to use a
FileDownloadDelegate
task to fish out the recommended file name.The
head
property is an explicitly unwrapped optional because there is no "default value" to set it to, and it won't be accessed by the user until it's already been set anyway. This is a little inelegant, so I could change it to something like below where I fill in bogus init data, but that seems worse for some reason.