Month: August 2009

August 7, 2009 Technology 17 Comments

Rebutting Big Nerd Ranch on Objective-C 2.0 dot notation

The Big Nerd Ranch weblog has a new post about Objective-C 2.0 dot notation. They advocate never using it and they’re completely wrong.

Given my reaction on Twitter, several people have asked me to write a more in-depth rebuttal.

I’ve already addressed when and why you should use Objective-C 2.0 properties and dot notation in an earlier post, so I won’t go into that here. I’ll just repeat my response to their weblog.

Here’s what I wrote in response:

> I disagree most emphatically. The whole point of dot notation is that, when combined with properties, it’s not *just* an alternative syntax for invoking methods. In fact, if that’s how you think about dot syntax, STOP. That’s not what it’s for at all.
>
> What dot syntax and property declarations are for is separating object *state* from object *behavior*. Classical OOP only really defines objects as only exposing behavior but the past 30+ years have demonstrated rather aptly that objects consist of both. C# was actually pioneering in this; its concept of properties is rather similar to what the combination of property declarations and dot syntax enable in Objective-C.
>
> To write idiomatic Objective-C 2.0 you should use `@property` to declare properties, and use dot syntax to access them. Period. Doing otherwise is a bad idea because it will create code that isn’t intention-revealing to other experienced Objective-C 2.0 developers. Teaching students to do otherwise is doing them a disservice, because you’re directly contradicting those responsible for the language and its evolution.

In short, Objective-C 2.0 has properties and dot notation as another way of expressing intent in your code. Use them for that, don’t refuse to use them just because they weren’t in earlier versions of the language, or because they require teaching another concept.

August 6, 2009 Technology 13 Comments

Using “en” instead of “English” for your Xcode project’s development region

Various pieces of Mac OS X and iPhone documentation have said for quite a while that the “preferred” method is now to use ISO-639-1 (two-letter) or ISO-639-2 (three-letter) language codes codes for localization purposes. Out of the box, Xcode’s project templates still use “English” rather than “en” as their default localization.

How can you use the ISO-639 language codes everywhere in your project, rather than in just your non-English localizations?

It’s pretty straightforward, but it does require hand-editing of your Xcode project file. This means that before doing anything else, you **must quit Xcode and Interface Builder**.

The first step is to rename your existing localizable resource directories *on disk* from `English.lproj` to `en.lproj`. You can do it at the Terminal or in the Finder. If you’re using an SCM system such as Subversion, use it to do the renaming so it preserves your file history and such as well.

The next step is to adjust how your existing localizable resources are referenced in your Xcode project file. Open the `project.pbxproj` file inside your Xcode project in a plain text editor such as TextEdit (rather than Xcode) and replace **all but one** occurrences of the string `English` with the string `en`. The one you don’t want to replace is in a property under the PBXProject section named `knownRegions`: This is an array of localizations Xcode knows about. Just make sure `en` is at the end of the array:

knownRegions = (
English,
Japanese,
French,
German,
en,
);

At this point, this should be the only place `English` appears in your `project.pbxproj` file.

Finally — and this is the important step, and non-discoverable step — you need to **add a property** to the `project.pbxproj` file to tell Xcode what the Development Region for your project is. Again, this gets put into the PBXProject section before the `knownRegions` key from above (Xcode will alphabetize the keys when saving your project for you); it should look like this:

developmentRegion = en;

The default value of this key within Xcode is `English` and Xcode won’t write the key into the project if the default isn’t changed. However, there’s no user interface within Xcode for actually changing this property, making it non-discoverable. Furthermore, if you are changing your project to use `en` as its default localization, and you *don’t* change this property, you won’t be able to add new localizations by inspecting your resources. (This is a known issue.)

At this point, you can save your modified `project.pbxproj` file and open your project again in Xcode. There’s one more thing you’ll have to change, this time in your product’s Info.plist file (or your products’ Info.plist files), before you can get back to work: You need to change the `CFBundleDevelopmentRegion` property to `en` rather than `English`.

Once you’ve made that change, you should safely be able to use your Xcode project normally, adding localized variants of your resources, building and running, and so on, and everything should Just Work — now using modern ISO language codes instead of the English language names!