search

novoda / download-manager

A library that handles long-running downloads, handling the network interactions and retrying downloads automatically after failures
Apache License 2.0
483 stars 63 forks source link

Need performance improvement for `onUpdate` call #467

Open pglebocki opened 5 years ago

pglebocki commented 5 years ago

There is following business scenario:

Observation. There is quite big time gap between download() and onUpdate(). In case of my app about 500 - 1500 ms. This is causing bad visual experiance because progress indicator is show after some visible delay.

Expectation: Queued status should be triggered immediately. Is it possible to get implement any improvement for that ?

zegnus commented 5 years ago

hi @pglebocki there is a parameter that you can add in the download manager builder that's for setting the speed at which you want to be updated (the progress bar, not the status of a batch). You can set it by progress or by time. Be aware that if you get callbacks too fast, the UI is not capable of refreshing the notifications UI as fast as you might think, as the callback is delivered in the UI thread you might need to handle that yourself.

If your issue is the name of the status itself (not the downloading progress bar), this could be because we have to request the file size before vetting the batch (notice that in the UI we show the total file size for all queued batches), I would need to double check though... Could that be this your scenario?

pglebocki commented 5 years ago

Hi @zegnus The speed of updating progress bar is not the problem. What I need is to get QUEUED status by onUpdate() to be triggered immediately. I understand that content-lenght, storage size etc.. need to be checked probably before calling onUpdate, so I takes time. Maybe it's possible to add some additional status like REQUESTED to be triggered just after calling download() ?

Mecharyry commented 5 years ago

Hi @pglebocki, I understand your problem. The issue is with the initial time it takes from requesting a download to the first status being emitted. This is indeed a problem, I believe this has come up in conversation before with @zegnus, I would be tempted to either create a new status that we can emit immediately or see if we can perform a bit of a rework to emit the QUEUED status straight away.

pglebocki commented 5 years ago

@Mecharyry @zegnus For me both solutions (reworking QUEUED / adding new status) are ok. I think implementing new status will be easier but it's about You guys. Thanks :)