Feature request: Image download progress information about alamofireimage HOT 20 CLOSED

This is certainly a valid request. The reason it wasn't added initially was that it didn't seem like the majority of users would need such a feature. Generally images download so quickly that showing progress ends up flashing rather showing a nice progress download unless the image is HUGE. With that said, I think there's certainly valid cases where progress would be really nice to track through the UIImageView extension or at least through the ImageDownloader.

I'll leave this open for others in the community to +1 if they want. Most likely we'll end up adding support for this, but it will require changes to multiple public APIs to do so. May have to be punted to AlamofireImage 3.0, but I think it could be done in a backwards compatible way.

from alamofireimage.

+1

from alamofireimage.

+1

from alamofireimage.

+1

from alamofireimage.

+1

Seem like at the very least you could support implicit composition of NSProgress without being too disruptive of the public APIs. Of course, that assumes your user is using NSProgress which may not be what you want to do.

from alamofireimage.

+1

from alamofireimage.

+1

from alamofireimage.

+1 I actually came here to make this feature request. I'd be willing to offer up help on this. Has anyone already started on this? Otherwise, when I get a chance, I'll start work on this from scratch!

from alamofireimage.

+1:

from alamofireimage.

+1

from alamofireimage.

I add that is needed to update the image progressively..as soon as a portion is downloaded we show it..this is beneficial for big images download.

from alamofireimage.

My apologies for not getting back to you sooner @AnthonyMDev. It would be awesome if you want to take a stab at this!

What I'm thinking for this feature is that you just need to first expose a progress closure at the ImageDownloader level. This should be pretty straight forward. It just needs to chain the closure onto the download request. The trickier part is how to bubble this up to the UIImageView extension without being too invasive. I'm afraid the only way to do it is to add another parameter to the af_setImage APIs. It needs to make sure to dispatch back to main since Alamofire doesn't do that automatically.

We could also add a progressQueue parameter on the ImageDownloader APIs that defaults to dispatch_queue_get_main(). That might be the best way to go, then the client knows what dispatch queue the progress closure will be called on.

If you want to take a stab and push up a PR for review part way through just for feedback, go for it. Before we merge, we'll want a set of full coverage tests around the progress logic.

Thanks again! 🍻

from alamofireimage.

@cnoon Sure, if I find time soon, I'll take a shot at it. And I always TDD, so tests are not a problem ;).

@dingua My initial thought was that there would be a circular progress indicator that would be overplayed on the UIImageView over the placeholderImage and then the image would still just be set when the download was completed. Rendering the partial image data is something that I have no experience with personally. I'm assuming it's not incredibly difficult, but I'm not sure how to implement that just yet, and it will be more complicated.
@cnoon Do you think that this is a good/necessary addition to this feature? I know that, in the application I'm currently building, I would not want partial images to render. I'd prefer to have the placeholder image remain with a progress indicator over the top until the image is completely loaded. So, I'm thinking that, if we do implement partial image rendering, it would need to be another option added.

I'm probably not going to try to implement that in my first iteration of this feature. I'd just like to get something working, and then we can add the partial image rendering later. Does that sound okay?

from alamofireimage.

Another question came up as I began thinking about how to implement this. I'm not 100% clear on the desired functionality here.
Options:

• Expose a progress closure to the af_setImage methods.
• Include a showProgressIndicator: Bool parameter on the af_setImage methods.

If we expose an actual progress closure, there is more flexibility for the user to do whatever they want. However, most people are just going to want to display a simple progress indicator, and it will be much more usable for most people if we implement that for them.

I'm thinking that we should probably implement both methods for the most flexibility.

I'm also considering adding another option where the user can pass in a custom progress indicator that would be a UIView subclass conforming to a ProgressIndicatorType.

@cnoon Thoughts?

from alamofireimage.

Okay, well I've started by adding the progress and progressQueue parameters to ImageDownloader, but the UIImageView APIs are starting to get really messy with the number of methods that are needed to handle every set of possible configuration options. I think we need to discuss fixing the way we do these APIs. I've started #80 to discuss this.

This feature is going to have to be put on hold until we have resolved that issue.

from alamofireimage.

Hey @AnthonyMDev, I don't know where the idea of a progress indicator came into play, but I'm thinking that's not a good idea. As soon as we add something, someone else is going to want something different. By only exposing the progress data in the progress closure, users can create any UI they want inside the UIImageView. Let's keep the first iteration of this as simple as possible. We can always add more functionality in the future if there's still a gap.

from alamofireimage.

+1, I'm converting from SDWebImage and was using this capability.

from alamofireimage.

@markkrenek This kind of took a back seat for me, as I've been working on a bunch of other stuff recently. I'll try to finish this up this week if possible.

from alamofireimage.

Okay, pull request made!

from alamofireimage.

I'm going to close this issue out. Please redirect all further comments to PR #91.

from alamofireimage.