> On 5 Apr 2016, at 10:19, Quincey Morris <quinceymor...@rivergatesoftware.com> > wrote: > > On Apr 4, 2016, at 18:16 , Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote: >> >> The importing iOS app has both exported and imported UTI defined (not sure >> what is really needed). >> >> But when the Document Types is only “my.private.uti”, then I am not asked to >> open in which app (good) but no data is received (bad). >> If Document Types is only “public.data”, I get several apps to choose from. >> Choosing my app, the data is delivered. >> >> The magic is to have 2 Document Types: “my.private.uti” + “public.data”. >> Now on receiving the data I get not asked to choose an app (as there is only >> one: mine) and the data arrives safely and is processed. > > This sounds wrong. > > First, do NOT define the same UTI identifier in both the Imported UTIs and > Exported UTIs section of the plist. Note that “import” and “export” here > don’t refer to the documents or data, but to the UTI itself. An exported UTI > is one that the app owns/defines, and the Exported UTI definition *is* the > definition. An imported UTI is one that’s owned/defined by another app, but > this app *uses*, and provides details in case the owner is not installed. In > your case, you want to export the definition, because your app owns the > custom UTI. However, I doubt that this in itself is causing any strange > behavior, assuming the import and export definition are identical.
As I wrote in a follow up: declaring UTIs is not necessary for the importing iOS app at all. > > Second, the idea that your custom UTI can trigger your iOS app, but not > supply it with data is bizarre. It actually sounds like there is something > wrong with one of your definitions, as if conformance to public.data isn’t > specified in the Exported UTI on iOS. > > Are you following all the guidelines laid out in > https://developer.apple.com/library/ios/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html > under heading “Supporting AirDrop” and subheading "Receiving Files and Data > Sent to Your App”? Almost. I did not: “Be prepared to look for files in your app’s Documents/Inbox directory and move them out of that directory as needed.” I just rely on application:openURL:options: being called. (application:openURL:sourceApplication:annotation: is deprecated). Well I did look (just for fun): With one Document Type = “my.own.uti” air-dropping the file shows “Air Drop <my name> is sharing <my file> Cancel”, but then my app does NOT get activated, and when I activate it myself, there is nothing in the Inbox. With both “my.own.uti” and “public.data” my app DOES get activated and application:openURL:options: is being called (as it should). This behaviour might rightly be called “bizarre”; it did not find it documented anywhere, but still: this is what my tests show. Kind regards, Gerriet. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
