On Mar 2, 2017, at 11:38 , Daryle Walker <dary...@mac.com> wrote:
>
> I’m trying out my document-based Mac app’s data-read routine, and the code it
> being skipped. I actually check the typeName (i.e. the UTI) and it doesn’t
> match. My bundle identifier for the app has capital letters. I base my
> document’s main type off that identifier, so it also has capital letters.
> Turns out that the system gives me the UTI in all small letters, so my
> (Swift) “switch” fails and my no-matching-type code is executed. I know I
> could switch my bundle ID to all small letters, but I want to know first if
> this is documented? Or is the small-letters transformation a bug?
I don’t know exactly what the rules are. The documentation:
https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_conc/understand_utis_conc.html
<https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/understanding_utis/understand_utis_conc/understand_utis_conc.html>
explicitly includes upper and lower case in the set of valid characters, but
says nothing about case sensitivity or equivalence. Given that case is not
significant (to you, that is) in the system of strings you’ve described, you
could simply work around the problem by using “<string>.lowercase” instead of
“<string>” at any point of comparison.
FWIW, I generally follow these principles when designing identifier strings:
— Never use upper case in bundle IDs. Irritatingly, a new Xcode project
parameterizes the bundle ID by appending the product name, which typically has
mixed case. I edit the bundle ID to a lower-case literal string as soon as I
create the project.
There have be other similar situations in the past where the bundle ID failed
to match because of case differences only. Since you can’t change the bundle ID
once it hits iTunes Connect, I think it’s safer to lower-case it from the start.
— Don’t construct bundle ID strings and other similarly-structured strings in
source files by combining prefixes and suffixes (some of which may be shared
substrings). Instead, spell out the entire string in each case, and make it a
global constant with a symbolic name. (Better still, in Swift, make appropriate
global enums with the strings as the associated values of the cases. Strict
type checking FTW!) Combining shared substrings, especially when done as a
mixture of compile-time and run-time operations, is a potential source of
future annoying bugs.
— There’s no particular value in basing a UTI on a bundle ID. A UTI may well
outlive the bundle ID of the app that introduces it.
In many cases, the natural thing to do will be to include the app name in the
UTI, so it will look similar to the bundle ID. But there’s no need to strive
for congruence.
_______________________________________________
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
