On Jul 4, 2013, at 19:30 , Stephen Kay < email@hidden> wrote: Is there something I could be or should be doing, so that if a user installs
more than one flavor of the app, the documents for each app will be assigned
to point to the correct "open with" app and icon?
I gather this is a Launch Services issue, but I don't know if there is some
script I should be running or something to tell Launch Services how to
correctly interpret the relationships of the files to the second installed
app.
It's not a Launch Services issue, because Launch Services isn't designed to support this scenario (distinguishing between types on something other than extension, when an extension is specified).
What is the behavior you're looking to implement here? According to your description, if the user has only one of the apps installed, documents from both apps will be opened by the installed app, and the documents will all have the icon of the installed app. Is that what you want, or do you want document created somewhere else by the not-installed app to have their original icon?
If both apps are installed, you seem to be implying, the documents should be opened by their originating app. If so, the document types really are different, and so should have a different, distinguishing extension. (Don't follow the creator ID fantasy. Creator IDs are deprecated, so they don't lead you anywhere good in the future.)
I would be inclined to suggest that you define 3 UTIs in the app bundle for each app:
and associate extensions .kdf,.kdfa, .kdfb with each UTI.
Application A should define 'com.you.music-keyboard-a' as an exported UTI and the other 2 as imported UTIs. Application B should define 'com.you.music-keyboard-b' as an exported UTI and the other 2 as imported UTIs. The icon for 'com.you.music-keyboard' should be the same in both cases, and the other icons should be different from it and each other**. The role for all 3 UTIs should be 'editor'.
Both app A and app B will then be able to open and edit all 3 extensions. If both are present, an A or B document will be opened by the originating app, and the non-A non-B documents will be opened by whichever app Launch Services picks (probably the most recent).
You would complete this picture by putting logic into your apps to change doc types (switch extensions) on a save according to logic you decide. For example, you may choose to change B docs to A docs when edited by the A app, or only change them when app B isn't installed, or not to change them at all.
I can only see 2 downsides to this:
1. Your A and B doc types won't open on a Mac that doesn't have a newish version of app A or app B. (You might need some kind of non-A non-B export to cover this.)
2. Users will see up to 3 extensions when they used to only one. This seems likely to be a non-issue, though, if they open with the expected app.
** You can probably play games with the import UTI definitions to have the icon and document type description be the ones of the app containing the definitions, rather than being the same for both apps. I think Launch Services will then show the app A icons/descriptions if app A is the only one installed, similarly if app B is the only one, and different icons when both are installed. (IOW, I think Launch Services will prefer export UTI properties over import UTI properties.) This might or might not be what you want.
|