locked
BackgroundDownloader.CreateDownload() design flaw

    General discussion

  • When my internet decided to go on brief holiday today, I discovered that the function BackgroundDownloader.CreateDownload() has the potential to take a long time to finish even though it is not a async function.

    From what I have observed, I believe CreateDownload() tries to resolve the URI passed to it. However if one is on a network with "limited connectivity", aka no internet, then the function will keep trying for a period of time (around 10-20 seconds) till it finally gives up. 

    I am of the opinion that CreateDownload() either needs to be made into an asynchronous function or BackgroundDownloader needs to be re-factored. 

    Tuesday, April 03, 2012 3:04 AM

All replies

  • Hello,

    Thanks for your feedback, I will involve more experts to investigate it.

    Best regards,
    Jesse


    Jesse Jiang [MSFT]
    MSDN Community Support | Feedback to us


    • Edited by Jesse Jiang Wednesday, April 04, 2012 3:39 AM
    Wednesday, April 04, 2012 2:10 AM
  • Thanks for the feedback Chris. I've created a bug for you in the appropriate database.

    -Steve

    Friday, April 06, 2012 1:11 AM
    Moderator
  • Hi Chris,
     
    I have notified our team of your feedback.

    BackgroundDownloader.CreateDownload() does not resolve URI. It simply persists state (URI, headers, etc.) and creates required broker state such that the download may be hosted in a separate process thereby allowing it to run in the background once the app is suspended. It should not take 10-20 seconds and it is not using the network at all. So being on a slow network shouldn't matter as far as CreateDownload() execution is concerned. However, you may notice the lag if you create hundreds of download operations by invoking CreateDownload() through a loop. It may help to see how you are invoking CreateDownload() and what data you are passing into the download operation.


    Network Developer Experience Team (Microsoft)

    Wednesday, April 18, 2012 6:22 PM