Open SimonSimCity opened 8 years ago
Seems like there was a limit of 1000 lines in the queue, that got removed in Android 5.0.0: https://github.com/android/platform_packages_providers_downloadprovider/commit/dffbb9c4567e9d29d19964a83129e38dceab7055#diff-c98b2c2fe66ec5124246dd51f019e26aL135
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!
@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.
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:
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.