[Feature Request] Download List of Urls

[ghost1372]

Thanks for your very helpful library Some features seem to be missing And it is better to be supported I have a list of URLs and I want them to be downloaded in order It is also better to have a feature that allows us to download multiple files at the same time Something like this:

var mylist = ...
{
"url1",
"url2",
...
}

var downloader = new DownloadService(downloadOpt);
downloader.MaxNumberOfMultipleFileDownload = 2;
await downloader.DownloadFilesAsync(mylist);

[bezzad]

I trying to add this feature as soon as possible. Thanks for your feedback.

[ghost1372]

@bezzad thank you @lindexi how about this?Will you add this feature?

[lindexi]

@ghost1372 Sorry, I will not do that. Because we can do this in business code.

[ghost1372]

any news?

[GihanSoft]

@ghost1372 Sorry, I will not do that. Because we can do this in business code.

I thing it's better to be handled by client code. adding this in library is not good. At least using a subclass for it may be better.

[bezzad]

@GihanSoft that's right to handle it from the client-side. But I write a simple DownloadManager class that can be used to list IDownloadService and manage downloaders concurrency degrees.

When you want to use a list of downloaders and manage themselves manually, There may be some issues that are difficult to manage without the downloader, for example:

• handling progress events per each downloader
• handle download completion or cancellation events
• Know when you can start the next download in from queue
• Adding a new download to the list in progress time.
• ...

Anyway, you can have your download manager and don't use this new DownloadManager class and only have the Downloader in your program, because there will be no dependency between these two classes in this library.

I'm very glad of your opinion and feel free to request a new feature for the download manager or continue this discussion.

[GihanSoft]

@bezzad I think it's even better not adding this DownloadManager class in main package. I think putting it in another NuGet is better way.

[ghost1372]

@bezzad I think it's even better not adding this DownloadManager class in main package. I think putting it in another NuGet is better way.

I disagree

[bezzad]

@GihanSoft as I said, I agree with you, Because, when we use the download manager, we do not need a downloader, and vice versa, if we use the downloader directly, it means that we want to control the download process ourselves and we do not want the download manager to do it for us.

Therefore, the best thing to do at this point is to use a separate package from the downloader. For a better result, we can discuss again :)

[bezzad]

@ghost1372 Why you don't agree?

[ghost1372]

I think it's a small feature and, as you said, there's no need for dependency. this is an almost independent feature that has nothing to do with the DownloadService So we do not need to publish through another package! If this feature is implemented properly, It will meet many needs.

[bezzad]

@ghost1372, @GihanSoft I consulted with somebody in this regard. The result was that this feature is quite simple to implement on the same package (due to the simplicity and closeness of this concept to the downloader package). But if there will be a lot of feature requests for about download manager in the future, which would make the project larger, then that would make sense to separate it from the project and package it independently.

If there is an issue, raise it here. Thanks

[ghost1372]

@ghost1372, @GihanSoft I consulted with somebody in this regard. The result was that this feature is quite simple to implement on the same package (due to the simplicity and closeness of this concept to the downloader package). But if there will be a lot of feature requests for about download manager in the future, which would make the project larger, then that would make sense to separate it from the project and package it independently.

If there is an issue, raise it here. Thanks

now i agree 😅

[RuddyOne]

@bezzad So is another project taking over this feature request or is this something for users of the package to handle?

Little confused as the issue has not been closed.

[bezzad]

@Ruddy2007 This feature is out of this project goal and if we want to create a class to manage a list of downloads, it will be upper level than the DownloaderService and it can't be implemented now. I decided to create a new project to do this feature.

[RuddyOne]

@bezzad Really random but I have just come across the need for the feature/project. Did you ever end up creating the project to handle this?

I am in need of a downloader that can download 1000's of files (images, videos etc). I would like it be done as fast a possible. Using this library is great but will do it 1 by 1 (as far as I can tell). So I will need to create a layer to handle concurrent downloads but it seems to be a little on the slow side (not sure if that's my doing or not). Should this library work with concurrent downloads or is it not designed for that?

[ghost1372]

@bezzad Really random but I have just come across the need for the feature/project. Did you ever end up creating the project to handle this?

I am in need of a downloader that can download 1000's of files (images, videos etc). I would like it be done as fast a possible. Using this library is great but will do it 1 by 1 (as far as I can tell). So I will need to create a layer to handle concurrent downloads but it seems to be a little on the slow side (not sure if that's my doing or not). Should this library work with concurrent downloads or is it not designed for that?

hmm.... take a look here https://github.com/ghost1372/ArtWork/blob/77ff0ecd229227c3e50c867dddf76aa80a7df705/dev/ViewModels/DownloadViewModel.cs#L175

[RuddyOne]

@ghost1372 Nice one, I will take a look and see if this will fit my needs. This is for a MAUI app so the ViewModel is pretty useful.

Just wondering if the download speed is going to be good enough. Last time I ended up writing my own downloader using HTTPClient and I think it ended up being faster. But then I had to maintain it etc.

We shall see, thanks again.