[Discussion] What's a reasonable amount of downloads the native DownloadManager should be able to handle?

[SimonSimCity]

Some of the native DownloadManager implementations seem to have limitations in either memory or amount of items you can add to the queue.

Here's a quote for iOS, where it seems like a memory limitation:

There is no good way to download 10,000 to 20,000 individual resources. Specifically:

• Background sessions were designed for a relatively small number of large items and you will not get acceptable result if you feed a background session this many items. If you submit them all at once, nsurlsessiond will choke; if you batch, the resume rate limiter will ruin your day.
• Foreground sessions are rated for this sort of work, but downloading this many resources will take too long to reasonably do in a foreground session.

Source: https://forums.developer.apple.com/thread/11621#31736

The recommended to batch the download-requests if you get over 100 on iOS.

Please also find out if that's needed on Android.

[SimonSimCity]

Seems like there was a limit of 1000 lines in the queue, that got removed in Android 5.0.0: aosp-mirror/platform_packages_providers_downloadprovider@dffbb9c#diff-c98b2c2fe66ec5124246dd51f019e26aL135

[joehanna]

Hi @SimonSimCity - thanks for building a great project. I am keen to implement this but I cannot get my head around how I can submit multiple files (say up to 30) without specifying the full destination path name with each one. I can't see how this solution works when submitting multiple files.

I couldn't find a sample where I could submit say 5 files, each with different destinations and names that vary from the source without managing some form of global Dictionary so it can be accessed from ExtendedUrlSessionDownloadDelegate.

Am I missing something?

Thanks!

[SimonSimCity]

@joehanna Sorry, I somehow overlooked the notification I got here ...

No, that's pretty much how it works. This is because of the major differences in implementation on Android and iOS - I didn't know of how the implementation for UWP worked when I started this project and now I don't see it as major necessity since Windows Phone practically died (https://www.theverge.com/2016/1/28/10864034/windows-phone-is-dead).

Android wants to know the final destination before the download is given to the native download manager, which could also be replaced by our own implementation (see #34).

iOS doesn't care that we want the file a different place, but just downloads it to a temporary folder where I can move it away from once it's downloaded.

This gap requires the library here to be able to determine the final location at any given time. It could e.g. be that your iOS device get's a wake-up after it was kicked out of memory being idle in the background for a while and now receives the hint that the download has finished. Your app must then within a very short amount of time find out what to do before the OS puts it to sleep again.

This issue here is about the recommended maximum amount of files you put into the queue of the native download managers. It does not only include hard limits but also tests on performance and battery consumption. Would be nice if you'd still have the time to take this up.