cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Want to learn some quick and useful tips to make your day easier? Check out how Calvin uses Replay to get feedback from other teams at Dropbox here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iOS 11 - Dropbox app not handling NSURLs from UIActivityItemProvider objects

iOS 11 - Dropbox app not handling NSURLs from UIActivityItemProvider objects

Danny_H11
Helpful | Level 6
Go to solution

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

1 Accepted Solution

Accepted Solutions

Danny_H11
Helpful | Level 6
Go to 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

View solution in original post

6 Replies 6

Greg-DB
Dropbox Staff
Go to solution
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
Dropbox Staff
Go to solution

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
Helpful | Level 6
Go to solution

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
Helpful | Level 6
Go to 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 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
Helpful | Level 6
Go to 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
Dropbox Staff
Go to solution

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

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

iOS Developer @Dropbox

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Ashasverus Dropbox Staff
  • User avatar
    Danny_H11 Helpful | Level 6
What do Dropbox user levels mean?