Curious about A, B, C, and D drives? Learn what they mean and how to use them effectively with Dropbox in this handy guide! - check it out now!
Forum Discussion
Danny_H11
8 years agoHelpful | Level 6
iOS 11 - Dropbox app not handling NSURLs from UIActivityItemProvider objects
Hi My iOS apps allow users to interact with their data objects and share them in several different ways via UIActivityItemProvider objects in a UIActivityViewController. These include text string...
- 8 years ago
You can close this question...I discovered either the problem, my own bug or a workaround - not sure which. I do not think this ever was a Dropbox issue. I'm familiar with the calls made to UIApplication for incoming files. Due to the nature of the solution, I don't think the file was being ignored by Dropbox, but was probably never even passed to it by iOS to begin with.
My fix...
In my code, I have different custom objects that respond to the UIActivityItemSource protocol. I supply them to varying UIActivityViewControllers across my app. These objects are init'ed with a placeholder item which, according to Apple's docs, can be empty - as long as it is the same class I plan to supply later when the user chooses an action. I return that placeholder item when asked by the UIActivityViewController according to the UIActivityItemSource protocol.
Assuming the name was unmimportant, I used to create these objects with a placeholder file URL as following.
DHDatabaseExportActivityItemSource *p = [[[DHDatabaseExportActivityItemSource alloc] initWithPlaceholderItem:[NSURL fileURLWithPath:@"something"]] autorelease];
That worked fine, until recently - probably after recompiling with iOS 11. But, updating the fake name to include an extension of the type I plan to supply later solves the issue, e.g. “Something.sqlite”. Now the file is successfully passed to the Dropbox App. Just to be safe, I go ahead and prepare the real name I plan on using, e.g.
DHDatabaseExportActivityItemSource *p = [[[DHDatabaseExportActivityItemSource alloc] initWithPlaceholderItem:[NSURL fileURLWithPath:@“My Database.sqlite"]] autorelease];
So - sorry to waste time. I don't really think this is Dropbox's fault. But, perhaps a future googler will get some help by reading this, since something, somewhere has definitely changed.
Kind regards,
Danny
Ashasverus
Dropbox Staff
8 years agoHi Danny,
There was an issue with file URLs handling in iOS 11 but we believe it should be fixed in Dropbox version 66 and above (current version at the time of writing this is 68 ). Could you please check it against those versions?
Thanks
------------------------------
iOS Developer @ Dropbox
Danny_H11
8 years agoHelpful | Level 6
Hi - thanks for helping.
Unfortunately, I just tested with iOS 11 and Dropbox version 68.2.2 - it's still not handling those file URLs. Oddly, I now realize it's not working on iOS 10 at the moment either.
Before, when file URLs were passed to Dropbox (via a "Copy to" or "Import to" operation from either a UIActivityViewController or UIDocumentInteractionController), Dropbox would silently import the document to the default App directory, and it would sync with your servers as expected. There was no indication that it had completed - which was fine. But, at some point, Dropbox began activating and prompting for a specific directory for these URLs. My users back up large SQLITE databases regularly with this feature, and I'm worried that (given the old behavior they are used to) they will not realize the action is not completing, until they need to restore a backup, and it's too late.
Thanks
Danny
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.5,961 PostsLatest Activity: 3 hours ago
If you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!