You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
DbxClientV2.sharing().listFolderMembers does not return user
I have some folder which is shared with this email: test@test.com. (I guess that such a dropbox account does not exist). Anyway if I use java api call: DbxClientV2 client;//some client String sha...
programmer wrote:And how can I get a SharedFolderMembers instance, ...
Hm..🤔 What are you calling your getUsers() upon? What type is that object? 🧐 🙋
Greg-DB
Dropbox Staff
Dropbox Staffprogrammer Здравко is correct; the getUsers method will only give you the members. To get the invitees, you'd need to call getInvitees.
Look at this:
I've got no idea why they marked this as spam. Are you going to answer me?
Hi again programmer,
Sometimes the forum spam filter activates just so - nobody knows why. 🤷 Don't ask me.
Anyways... Your issue is not related to Dropbox itself (neither Dropbox API nor Dropbox SDK). There are are lots of reasons why your link could slow down. To one or other extent it's always related to your application design. The initial source of such issues are usually outside the application though.
If I have to speculate, most likely your ISP slow down your prolonged network links. Such a practice is something very popular at present. It lets your ISP(s) to promise you network parameters that exceed real provider capacity and lets you feel that everything is well (in fact this is kind of fraud - very difficult to prove though). On link establishment the speed is high. So if you load a web page, for instance, despite of the delay, initial view appears fast that lefts impression of high speed. If you try download a big file on the same browser, for instance, the "picture" is different - the downloading throttles short after initiation. Keep in mind that by default the underlying network libraries concatenate successive request to the same domain as a single link (or few links - not link for every request)! This usually avoid initial delay related to link establishment, so speeds up requests performed on network environment with uniform speed. All good but this triggers ISP driven effects (something that usually the libraries don't take into account and is something specific to particular ISP). Again, despite this is something very likely, it's my speculation - you have to check the actual reason. If this confirms, you may try 'enpack' your download requests in smaller links - flush links pool from time to time when many requests become in queue (this is below Dropbox SDK). You may play with the different 'pack' sizes and see what works best. Keep in mind - too small packs will slow down because many link establishments, on one side, too big packs will trigger ISP throttling, on other side.
Good luck.
Unfortunately the issue is not about my ISP. The same application code works fine for hours if using google drive.
Unfortunately, that's very difficult to diagnose. Also keep in mind that it doesn't matter how long particular code works! So:
programmer wrote:... works fine for hours if using google drive.
... is unrelated, the important thing is how! If you keep doubt that it's Dropbox server related, try investigate outside your application with network diagnostic tools. Tools that may let you know what actually goes on. Try reproduce the same situation and observe results. I cannot say anything more.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
