Exclusively use inferred type identifiers

[irace]

Related: #49

We should be able to lazily provide items that don’t match the placeholder’s type, in order to e.g. provide a GIF if the message activity is selected. This requires using our function to calculate the item’s type rather than the type identifier that was provided when the item source was initialized.

The only other place where self.typeIdentifier was being used was in the UIActivityItemSource protocol’s activityViewController:dataTypeIdentifierForActivityType: method, but that seemed to be causing a problem due to the mismatch. I’ve removed it and everything seems to work fine.

Totally possible that I’m overlooking something here – please take a look through and let me know if you think this is necessary for some reason.

[AriX]

This definitely won't work. Passing in the type identifier is necessary in a number of cases, including:

• Specifying the type identifier for a data block (data blobs are useless without knowing what type they are - kUTTypeData is not meaningful, and the changes in this PR will break all sharing of NSData objects)
• Specifying the type identifier for data or file URLs provided by blocks - we need to tell the UIActivityViewController what type the file is before we provide the actual activity item (otherwise it will have no idea what activities are relevant)
• Advertising an item that represents a more specific type than its underlying object (for example, the OnePassword extension's types that conform to public.url)

The only changes you need to make in order to satisfy #49 are:

• Making the provider blocks use an id return type
• When creating the mainAttachment item provider, check if the class of activityItem is the same as self.placeholderItem. If it is, use self.typeIdentifier. Otherwise, use typeIdentifierForActivityItem() (and if typeIdentifierForActivityItem() returns nil, use self.typeIdentifier - in case the activity item being passed is NSData or anything else that does not imply a type)

All of the other changes in a4ce4c6 should be reverted in order to not break existing functionality.

[irace]

Data blobs are useless without knowing what type they are - kUTTypeData is not meaningful, and the changes in this PR will break the sharing of any data

Not explicitly true. Sharing a GIF to the Message activity works just fine with no type specified

The only changes you need to make in order to satisfy #49 are...

Not true. I’m unable to successfully provide GIF data to the Message activity so long as I am returning self.typeIdentifier from activityViewController:dataTypeIdentifierForActivityType:. Not implementing that method works.

We need to tell the UIActivityViewController what type the file is before we provide the actual activity item (otherwise it will have no idea what activities are relevant)

Yeah this is true. We could get rid of those initializers...?

[AriX]

Can you give me a quick code sample of how you're using XExtensionItemSource to share your GIF data that doesn't work when activityViewController:dataTypeIdentifierForActivityType: is implemented? I'd love to dive in and figure out what's going on there.

I'm very concerned about removing type identifiers - even if iOS is able to automatically determine the type of data in cases like GIFs, this certainly won't work for all files (and even if it works for Messages, does it work for general share extensions)?

[AriX]

I implemented my proposal here and sharing GIFs via Messages works great using something like XExtensionItemSource *itemSource = [[XExtensionItemSource alloc] initWithData:[NSData dataWithContentsOfURL:[[NSBundle mainBundle] URLForResource:@"example" withExtension:@"gif"]] typeIdentifier:(id)kUTTypeGIF].

Any more details on what's going wrong in your case?

[irace]

In my case I’m not providing kUTTypeGIF as the type identifier because the placeholder is of type NSURL

[AriX]

I see. I can confirm that behavior too - if you tell it you're giving it a kUTTypeURL, Messages won't successfully attach an animated GIF from an NSData object. You can work around it simply by writing the GIF to a file and returning the file URL as the activity item.

Though it'd be nice to be able to attach NSData rather than a URL, I really don't think this outweighs the lost functionality if we removed the other stuff. Thoughts?