nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Child Item

-downloadUrl seems much slower than DBRestClient's loadFile:dropboxPath

Gregg W.1

It seems that the iOS Objective-C framework support for the Dropbox API v2 is much slower at downloading large numbers (200+) of files than the original DBRestClient method.

For example in my iOS app...

v1 used this method...

[restClient loadFile:dropboxPath intoPath:localPath];

which would then do a callback to..,

-(void)loadedFile:(NSString *)localPath etc.

--------------------------------

v2 uses this method...

[dbClient.filesRoutes downloadUrl:remoteFilePath overwrite:YES destination:destinationURL]

With completion passing to the downloadUrl responseBlock.

---------------------------------

The original restClient method would download 250 files (10K each) in about 30 seconds and the new completionBlock method takes over a minute to download the same files on the same network and the same device.

Can anyone offer any insight as to why I am seeing such a slower download time with the new framework/API?

Is there a way to download the entire contents of a folder with a single call?

I am using ObjectiveDropboxOfficial v3.1.1 as an embedded xCode project but have seen the same results as far back as v3.0.1.

Thanks for any thoughts on this.

Find more posts tagged with

API

Abuse

Comments

Greg-DB

The two SDKs don't share any code, so it wouldn't be surprising if they have different performance characteristics.

In some quick testing though, I'm not seeing quite the disparity you are. Are you running multiple downloads simultaneously? If so, how many, and are you doing the same with both SDKs?

In any case, there isn't a way to download files in bulk, but I'll pass this along as a feature request.

Gregg W.1

Regarding multiple downloads: I have a 'fifo-spool' that limits the number of outstanding requests that are passed to the Dropbox framework. I've tried adjusting the limit between 25 and 500 simultaneous downloads and still see basically the same download times.

The repsonseBlock paradigm is rather new to me so I may be doing something wrong in that area.

What I am hearing from you is that the problem is on my end, and that is what I suspected. I just wanted some confirmation on that.

Thanks for your thoughts on this.

Greg-DB

Thanks for the additional information. There are many different variables that can affect speeds like this of course, so it can be ****** to say what's happening off hand. Let us know if there's something we can help with. For example, if you'd like to share your code, we can take a look and let you know if something looks wrong.

Also, it may be worth trying even fewer than 25 simultaneous downloads.