iOS 11 - Dropbox app not handling NSURLs from UIActivityItemProvider objects

[Danny_H11]

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 strings for SMS, email and social sharing; XML and tab delimited text for spreadsheet applications; and NSURLs for “Open In” functionality and uploading to Dropbox and iCloud.

In iOS 11, I’ve noticed that whenever a user taps the “Copy to Dropbox” icon provided by iOS, the file is never processed by the Dropbox app. My UIActivityItemProvider object create the NSURL as expected, but the Dropbox app never uploads it. If the user chooses “Save to Files”, and selects “Dropbox”, the file is uploaded as expected.

Also, in other areas of my apps, I allow users to create a PDF. In those instances, I use a UIDocumentInteractionController which also provides an NSURL of the file. If a user chooses “Copy to Dropbox” in those situations, all is well and the file is correctly handled by the Dropbox app.

So it seems that the Dropbox app is ignoring NSURLs supplied via a UIActivityViewController but correctly processing NSURLs supplied via a UIDocumentInteractionController.

How can I regain the former NSURL functionality that Dropbox used to provide with a UIActivityViewContoller? Or, is this a bug in the current Dropbox app?

Thanks

Danny

[Greg-DB]

Hi Danny, thank for the report. I'm sending this along to the right people to take a look. Thanks in advance for your patience.

[Ashasverus]

Hi 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]

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

[Danny_H11]

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 umimportant, I used to create these objects with a placeholder 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, and the file is successfully passed to the Dropbox App:

DHDatabaseExportActivityItemSource *p = [[[DHDatabaseExportActivityItemSource alloc] initWithPlaceholderItem:[NSURL fileURLWithPath:@"Something.sqlite"]] autorelease];

So - sorry to waste your time. I don't really think this is Dropbox's fault. But, perhaps a future googler will get some help at some point since something, somewhere has definitely changed.

Kind regards

Danny

[Danny_H11 · Accepted solution]

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]

I'm glad you were able to figure it out. Thanks for letting us know what helped!

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

iOS Developer @Dropbox