The Objective-C runtime lets you modify the mappings from a selector (method name) to an implementation (the method code itself). This allows you to "patch" methods in code you don't have the source to (AppKit, FoundationKit, etc). Unlike creating a category method with the same name as the original method (effectively replacing the original method), MethodSwizzling lets your replacement method make use of the original method, almost like subclassing.

This is best used in cases where a single method needs substitution or extension; If you need to modify many behaviors of a class, you may be better off usingClassPosing.

December 29, 2007: [http://mjtsai.com/blog/2007/12/29/jrswizzle/] Jonathan Rentzsch has started a project, JRSwizzle? [http://github.com/rentzsch/jrswizzle], to implement method swizzling correctly with different versions of the Objective-C runtime:

There’s at least four swizzling implementations floating around. Here’s a comparison chart to help you make sense of how they relate to each other and why JRSwizzle?exists.

For instance, let's pretend there's a class called Foo that implements the following method:

// returns the login name of the current user - (NSString *)fooBar;

Now we've got applications that call [[Foo sharedFoo] fooBar] all over the place; We'd like to modify the functionality of the fooBar method to append something silly to the result of the original fooBar return value.

So, we'll implement a category method that does the work:

@implementation Foo(specialfooBar) // returns the login name of the current user plus some other junk - (NSString *)myfooBar {     return [[self myfooBar] stringByAppendingString:@", bigtime luser"]; } @end

"But wait", I hear you saying, "the myfooBar method is calling itself, generating infinite recursion!" Well, that would be the case except for the fact that we're going to do some MethodSwizzling and swap the implementations of the two methods! Here's the deal: Right now, any code that calls -[Foo fooBar] is going to use the original implementation (let's call that "A"), and any code that calls -[Foo myfooBar] is going to use our new implementation (let's call that "B"). To summarize:

selector "fooBar"    ->  implementation "A" selector "myfooBar"  ->  implementation "B"  - implementation "A" returns @"username" - implementation "B" calls "myfooBar",   appends some silly text, and returns that

So right now, calling "fooBar" invokes implementation "A" like it always has; Calling "myfooBar", however, invokes implementation "B", which in turn calls "myfooBar", which invokes implementation "B", etc, leading to the unwanted infinite recursion.

// Do the swizzling (see below for the function code) MethodSwizzle([Foo class],               @selector(fooBar)               @selector(myfooBar));

After swizzling the two methods, we have the following situation:

selector "fooBar"    ->  implementation "B" selector "myfooBar"  ->  implementation "A"  - implementation "A" returns @"username" - implementation "B" calls "myfooBar",   appends some silly text, and returns that

Now, after the swizzling, anybody who calls "fooBar" will invoke implementation "B", which calls "myfooBar" (invoking implementation "A" and appending some silly text). In short, calling "fooBar" will now return @"username, bigtime luser"!

Hopefully this makes sense to people!

--JackNutting

Here's a C-function that does the trick:

#import </usr/include/objc/objc-class.h> void MethodSwizzle(Class aClass, SEL orig_sel, SEL alt_sel) {     Method orig_method = nil, alt_method = nil;      // First, look for the methods     orig_method = class_getInstanceMethod(aClass, orig_sel);     alt_method = class_getInstanceMethod(aClass, alt_sel);      // If both are found, swizzle them     if ((orig_method != nil) && (alt_method != nil))         {         char *temp1;         IMP temp2;          temp1 = orig_method->method_types;         orig_method->method_types = alt_method->method_types;         alt_method->method_types = temp1;          temp2 = orig_method->method_imp;         orig_method->method_imp = alt_method->method_imp;         alt_method->method_imp = temp2;         } }

Here's code that uses it:

@interface T : NSObject { } - (void)swizzleMethod; @end @interface T (AltMethod) - (void)altMethod; @end  int main (int argc, const char * argv[]) {     T *t;     t = [[T alloc] init];     [t swizzleMethod];      NSLog(@"Methods swizzled");     MethodSwizzle([T class],                   @selector(swizzleMethod),                   @selector(altMethod));          [t swizzleMethod];     [t release];          return 0; }  @implementation T - (void)swizzleMethod {     NSLog(@"Original method called"); } @end  @implementation T (AltMethod) - (void)altMethod {     NSLog(@"Alternative method called");     [self altMethod]; } @end

Here's the output as logged:

2002-04-09 17:23:58.144 Swizzling[2285] Original method called 2002-04-09 17:23:58.148 Swizzling[2285] Methods swizzled 2002-04-09 17:23:58.150 Swizzling[2285] Alternative method called 2002-04-09 17:23:58.152 Swizzling[2285] Original method called

NextPrevious 
http://developer.apple.com/library/ios/documentation/cocoa/conceptual/KeyValueObserving/index.html 
Registering for Key-Value Observing 
In order to receive key-value observing notifications for a property, three things are required:

• The observed class must be key-value observing compliant for the property that you wish to observe.
• You must register the observing object with the observed object, using the method addObserver:forKeyPath:options:context:.
• The observing class must implement observeValueForKeyPath:ofObject:change:context:.

Important: Not all classes are KVO-compliant for all properties. You can ensure your own classes are KVO-compliant by following the steps described in “KVO Compliance.” Typically properties in Apple-supplied frameworks are only KVO-compliant if they are documented as such.

Registering as an Observer 
In order to be notified of changes to a property, an observing object must first register with the object to be observed by sending it an addObserver:forKeyPath:options:context: message, passing the observer object and the key path of the property to be observed. The options parameter specifies the information that is provided to the observer when a change notification is sent. Using the optionNSKeyValueObservingOptionOld specifies that the original object value is provided to the observer as an entry in the change dictionary. Specifying theNSKeyValueObservingOptionNew option provides the new value as an entry in the change dictionary. To receive both values, you would bitwise OR the option constants.

The example in Listing 1 demonstrates registering an inspector object for the propertyopeningBalance. 
Listing 1  Registering the inspector as an observer of the openingBalance property 
- (void)registerAsObserver     
{      
    /* 
     Register 'inspector' to receive change notifications for the "openingBalance" property of 
     the 'account' object and specify that both the old and new values of "openingBalance"     
     should be provided in the observe… method.
     */
    [account addObserver:inspector     
             forKeyPath:@"openingBalance"      
                 options:(NSKeyValueObservingOptionNew |       
                            NSKeyValueObservingOptionOld)      
                    context:NULL];     
}      
When you register an object as an observer, you can also provide a context pointer. The context pointer is provided to the observer when observeValueForKeyPath:ofObject:change:context: is invoked. The context pointer can be a C pointer or an object reference. The context pointer can be used as a unique identifier to determine the change that is being observed, or to provide some other data to the observer. The context pointer is not retained, and it is the responsibility of the application to ensure that it is not released before the observing object is removed as an observer.

Note: The key-value observing addObserver:forKeyPath:options:context: method does not retain the observing object or the observed objects. You need to review your application’s requirements and manage retain and release for the observing, and observed, objects.

Receiving Notification of a Change 
When the value of an observed property of an object changes, the observer receives anobserveValueForKeyPath:ofObject:change:context: message. All observers must implement this method.

The observer is provided the object and key path that triggered the observer notification, a dictionary containing details about the change, and the context pointer that was provided when the observer was registered.

The change dictionary entry NSKeyValueChangeKindKey provides information about the type of change that occurred. If the value of the observed object has changed, theNSKeyValueChangeKindKey entry returns NSKeyValueChangeSetting. Depending on the options specified when the observer was registered, the NSKeyValueChangeOldKey andNSKeyValueChangeNewKey entries in the change dictionary contain the values of the property before, and after, the change. If the property is an object, the value is provided directly. If the property is a scalar or a C structure, the value is wrapped in an NSValueobject (as with key-value coding).

If the observed property is a to-many relationship, the NSKeyValueChangeKindKey entry also indicates whether objects in the relationship were inserted, removed, or replaced by returning NSKeyValueChangeInsertion, NSKeyValueChangeRemoval, orNSKeyValueChangeReplacement, respectively.

The change dictionary entry for NSKeyValueChangeIndexesKey is an NSIndexSetobject specifying the indexes in the relationship that changed. IfNSKeyValueObservingOptionNew or NSKeyValueObservingOptionOld are specified as options when the observer is registered, the NSKeyValueChangeOldKey andNSKeyValueChangeNewKey entries in the change dictionary are arrays containing the values of the related objects before, and after, the change.

The example in Listing 2 shows the observeValueForKeyPath:ofObject:change:context: implementation for an inspector that reflects the old and new values of the property openingBalance, as registered in Listing 1.

Listing 2  Implementation of observeValueForKeyPath:ofObject:change:context: 
- (void)observeValueForKeyPath:(NSString *)keyPath     
                      ofObject:(id)object      
                        change:(NSDictionary *)change  
                       context:(void *)context 
{      
    if ([keyPath isEqual:@"openingBalance"]) { 
        [openingBalanceInspectorField setObjectValue:  
            [change objectForKey:NSKeyValueChangeNewKey]];     
    }  
    /* 
     Be sure to call the superclass's implementation *if it implements it*.    
     NSObject does not implement the method.   
     */
    [super observeValueForKeyPath:keyPath      
                         ofObject:object       
                           change:change       
                           context:context];   
}      
Removing an Object as an Observer 
You remove a key-value observer by sending the observed object aremoveObserver:forKeyPath: message, specifying the observing object and the key path. The example in Listing 3 removes the inspector as an observer of openingBalance.

Listing 3  Removing the inspector as an observer of openingBalance 
- (void)unregisterForChangeNotification
{      
    [observedObject removeObserver:inspector   
                    forKeyPath:@"openingBalance"];     
}      
If the context specified when the observer was registered is an object, it can be safely released only after removing the observer. After receiving a removeObserver:forKeyPath:message, the observing object will no longer receive any observeValueForKeyPath:ofObject:change:context: messages for the specified key path and object.

NextPrevious

© 2003, 2011 Apple Inc. All Rights Reserved. (Last updated: 2011-03-08)

Did this document help you? Yes It's good, but... Not helpful... 
Shop the Apple Online Store (1-800-MY-APPLE), visit an Apple Retail Store, or find areseller.

• Mailing Lists
• RSS Feeds

Copyright © 2010 Apple Inc. All rights reserved.

NextPrevious 
http://developer.apple.com/library/ios/documentation/cocoa/conceptual/KeyValueObserving/index.html 
KVO Compliance 
In order to be considered KVO-compliant for a specific property, a class must ensure the following:

• The class must be key-value coding compliant for the property, as specified in“Ensuring KVC Compliance”.

KVO supports the same data types as KVC.

• The class emits KVO change notifications for the property.

 

There are two techniques for ensuring the change notifications are emitted. Automatic support is provided by NSObject and is by default available for all properties of a class that are key-value coding compliant. Typically, if you follow standard Cocoa coding and naming conventions, you can use automatic change notifications—you don’t have to write any additional code.

Manual change notification provides additional control over when notifications are emitted, and requires additional coding. You can control automatic notifications for properties of your subclass by implementing the class method automaticallyNotifiesObserversForKey:.

[自：2种技术：自动提交和手动提交。] 
Automatic Change Notification 
[自：这种方法好像是默认的，我没有发现特殊的函数调用来触发自动Notification机制。] 
NSObject provides a basic implementation of automatic key-value change notification. Automatic key-value change notification informs observers of changes made using key-value compliant accessors, as well as the key-value coding methods. Automatic notification is also supported by the collection proxy objects returned by, for example,mutableArrayValueForKey:.

The examples shown in Listing 1 result in any observers of the property name to be notified of the change. 
Listing 1  Examples of method calls that cause KVO change notifications to be emitted 
// Call the accessor method.   
[account setName:@"Savings"];  
       
// Use setValue:forKey:.       
[account setValue:@"Savings" forKey:@"name"];  
       
// Use a key path, where 'account' is a kvc-compliant property of 'document'.  
[document setValue:@"Savings" forKeyPath:@"account.name"];     
       
// Use mutableArrayValueForKey: to retrieve a relationship proxy object.       
Transaction *newTransaction = <#Create a new transaction for the account#>;    
NSMutableArray *transactions = [account mutableArrayValueForKey:@"transactions"];      
[transactions addObject:newTransaction];       
Manual Change Notification 
Manual change notification provides more granular control over how and when notifications are sent to observers. This can be useful to help minimize triggering notifications that are unnecessary, or to group a number of changes into a single notification.

A class that implements manual notification must override the NSObject implementation ofautomaticallyNotifiesObserversForKey:. It is possible to use both automatic and manual observer notifications in the same class. For properties that perform manual notification, the subclass implementation of automaticallyNotifiesObserversForKey: should return NO. A subclass implementation should invoke super for any unrecognized keys. The example in Listing 2 enables manual notification for theopeningBalance property allowing the superclass to determine the notification for all other keys.

Listing 2  Example implementation of automaticallyNotifiesObserversForKey: 
+ (BOOL)automaticallyNotifiesObserversForKey:(NSString *)theKey {      
       
    BOOL automatic = NO;       
    if ([theKey isEqualToString:@"openingBalance"]) {  
        automatic = NO;
    } else {   
        automatic=[super automaticallyNotifiesObserversForKey:theKey]; 
    }  
    return automatic;  
}      
To implement manual observer notification, you invoke willChangeValueForKey: before changing the value, and didChangeValueForKey: after changing the value. The example in Listing 3 implements manual notifications for the openingBalance property.

Listing 3  Example accessor method implementing manual notification 
- (void)setOpeningBalance:(double)theBalance { 
    [self willChangeValueForKey:@"openingBalance"];    
    openingBalance=theBalance; 
    [self didChangeValueForKey:@"openingBalance"];     
}      
You can minimize sending unnecessary notifications by first checking if the value has changed. The example in Listing 4 tests the value of openingBalance and only provides the notification if it has changed.

Listing 4  Testing the value for change before providing notification 
- (void)setOpeningBalance:(double)theBalance { 
    if (theBalance != openingBalance) {
        [self willChangeValueForKey:@"openingBalance"];
        openingBalance=theBalance;     
        [self didChangeValueForKey:@"openingBalance"]; 
    }  
}      
If a single operation causes multiple keys to change you must nest the change notifications as shown in Listing 5.[自：注意：如果是2个以上的变化，则需要使用例子中的方法，而非单独Notification。]

Listing 5  Nesting change notifications for multiple keys 
- (void)setOpeningBalance:(double)theBalance { 
    [self willChangeValueForKey:@"openingBalance"];    
    [self willChangeValueForKey:@"itemChanged"];       
    openingBalance=theBalance; 
    itemChanged=itemChanged+1; 
    [self didChangeValueForKey:@"itemChanged"];
    [self didChangeValueForKey:@"openingBalance"];     
}      
In the case of an ordered to-many relationship, you must specify not only the key that changed, but also the type of change and the indexes of the objects involved. The type of change is an NSKeyValueChange that specifies NSKeyValueChangeInsertion,NSKeyValueChangeRemoval, or NSKeyValueChangeReplacement. The indexes of the affected objects are passed as an NSIndexSet object.

The code fragment in Listing 6 demonstrates how to wrap a deletion of objects in the to-many relationship transactions. 
Listing 6  Implementation of manual observer notification in a to-many relationship 
- (void)removeTransactionsAtIndexes:(NSIndexSet *)indexes {    
    [self willChange:NSKeyValueChangeRemoval   
     valuesAtIndexes:indexes forKey:@"transactions"];  
       
    // remove the transaction objects at the specified indexes here    
       
    [self didChange:NSKeyValueChangeRemoval    
    valuesAtIndexes:indexes forKey:@"transactions"];   
}      
Note: In a reference counted environment, ou must make sure that you do not release the values that will change before sending a willChange message.

NextPrevious

© 2003, 2011 Apple Inc. All Rights Reserved. (Last updated: 2011-03-08)

Did this document help you? Yes It's good, but... Not helpful... 
Shop the Apple Online Store (1-800-MY-APPLE), visit an Apple Retail Store, or find areseller.

• Mailing Lists
• RSS Feeds

Copyright © 2010 Apple Inc. All rights reserved.

• Terms of Use
• Privacy Policy

• Terms of Use
• Privacy Policy

+++++

日期：2011.08.01

User interface strings in Cocoa

In this post, I'll look at best practice for using and managing text strings in your user interface. This is a fairly simple topic but Cocoa has established "best practices" for handling user interface strings that new Cocoa developers should be aware of. Since it is inevitably related, I'll also look at the steps involved in localizing the strings in your applications but remember: you should follow good practice for string handling, even if you have no intention of ever translating your application.

Introduction (the wrong way)

Putting a text string in your user interface is not a difficult thing to do on a technical level. In code, filling in text can be as simple as setting the textproperty of a UILabel to a literal string:

someUserInterfaceLabel.text = @"Text to display";

(This code is for an iOS UILabel. On Mac OS X, you would set thestringValue property of an NSTextField but otherwise the step is the same.)

While this will work, you should never set a user interface string this way.

Setting labels with literal strings (the right way)

The most thorough way to put a literal string into your Cocoa application's user interface is:

someUserInterfaceLabel.text =
    NSLocalizedStringFromTable(
        @"Text to display",       // the native language string
        @"SomePageLabels",        // the category
        @"Label display string"); // a comment describing context

This is pretty verbose though. It is often okay to just use:

someUserInterfaceLabel.text = NSLocalizedString(@"Text to display", nil);

If you take no other steps, this will produce exact the same output as the "wrong way" example.

You should always use the NSLocalizedString[...] macros for every user interface string in your code.

But wait... this NSLocalizedString[...] stuff requires more typing and unless you take yet more additional steps, it won't have any functional difference? If I'm not planning to translate my program right now, aren't they a complete waste of time?

Why NSLocalizedString is important, even if you don't intend to translate

Obviously, the NSLocalizedString[...] functions (and the less commonCFCopyLocalizedString[...] variants) are functions that exist to enable localization (i.e. letting you translate your application into different languages).

Technically, they're not even functions — they're just macros that invoke the -[NSBundle localizedStringForKey:value:table:] method — but you should always use the macro and not the underlying method for reasons I'll discuss in the "Mechanics of Translation" section below.

However, even if you're not intending to ever localize your application, you should always use NSLocalizedString.

There are a few reasons for this:

1. Futureproofing: The future is hard to predict: you never know if you'll want to translate in the future. Needing to go through your code and find rogue literal strings is time consuming and prone to mistakes. Instead, everything should always have NSLocalizedString from the beginning.
2. MVC practices: It keeps the exact details of your model/presentation layer at least one level of indirection removed from your controller code. In some cases, you can simply change the .strings files for your program to update the user interface and not need to change code due to this separation.
3. Separation of concerns: It clearly identifies text strings intended for user presentation as opposed to text strings used as keys for programming use only.
4. Discourages other bad practices: with your user interface strings detached from your controller, you'll be less likely to try to read static strings back from the user interface (a very bad idea) or place programmer-targetted strings in the user-interface.

Get into the habit of using NSLocalizedString. It's really simple to do — even when you're hacking code together quickly, you should be able to use it.

The first two points in the previous list are self-explanatory but the second two merit further explanation.

Separation of concerns

It is always helpful in programming to be able to glance at code and understand the intent. Consider the following piece of code in isolation:

[someDictionary setObject:@"value" forKey:SomeKeyNameString];
[someDictionary setObject:NSLocalizedString(@"value", nil) forKey:SomeOtherKeyNameString];

Without knowing what someDictionary is for or what the purpose of theSomeKeyNameString and SomeOtherKeyNameString values are, we know that the second string is intended for display in the user interface at some point whereas the first string is purely for tracking a value internally.

This clear labelling of intent is helpful as strings for user display have a very different role in a program compared to strings for internal use.

Discourages other bad practices

If you treat NSLocalizedString in your mind as though its output is a black box, this can help you avoid poor controller design when managing user interface elements. It can act as a conceptual tool to encourage you to design things the right way, instead of a lazy way.

Your controller code should treat user interface strings as something that can be written but not read. Reading static strings back from the user interface is always bad (it ends up being a form of "common or data coupling" — a bad design practice).

In the "Separation of concerns" example above, you might consider that since the keys SomeKeyNameString and SomeOtherKeyNameString are defined in global variables in this example, that perhaps you'd want to define your localized strings in global variables. In most cases a global variable for a user string is actually a bad idea.

We define dictionary keys in global variables because more than one location in the program may need to use exact the same value or the exchange of information between the two points will fail. But with user interface strings, you should never have a second piece of code that requires the exact same value: you should never read back from the user interface or require user interface collusion. Generally, the only situation where the same string should appear multiple times is if the same user interface code is displaying it (i.e. you're drawing the same object) but in this case, the code is common and the string should only need to appear once in the code.

If you need to uniquely identify a label or the state of a text displaying item, testing the text it contains is the wrong way to do that. A far better way is to use the tag value of any UIView/NSActionCell and then map the tag value onto the object's role or function (tag is a pointer sized value so you can store a non-retained object reference here if needed, not just an integer). The tagproperty is not reserved for any other purpose; it is intended for the controller to track user interface items and their state.

Mechanics of translation (when you're ready)

Eventually, you may actually have to translate your program. Let's look at the steps involved.

Create your ".strings" files

The files you need to translate are the ".strings" files in your application. By default though, your project probably won't have any ".strings" files (except possibly an InfoPlist.strings file which is for translating your Info.plist file's strings).

The first step is to make sure you have a localized directory somewhere (probably in the Resources subdirectory of your project's folder). The localized directory should be named "en.lproj" if you're starting with English strings, otherwise you'll want to replace "en" with the appropriate ISO 639-1 or ISO 639-2 designators. If needed you can use the script and region identifiers too as described in Apple's Language and Locale Designations.

A note on folder names: it is common to see "English.lproj" used as the name for English localization instead of "en.lproj" — in fact, Xcode 3 still generates folders with this name if you Get Info on a file and select "Make file localizable". Apple have stated that these old, "full" names are deprecated from Mac OS X 10.4 onwards in favor of ISO 639-1 or ISO 639-2 designators. Don't use the old "English.proj" style names anymore and replace with "en.lproj" if it is autocreated (yes, you might need to update your Xcode paths if you change the folder name).

Now we can create ".strings" files automatically from all theNSLocalizedString references in your program. To do this, open a Terminal in your Project's root directory and run the following command:

find -E . -iregex '.*\.(m|h|mm)$' -print0 | xargs -0 genstrings -a -o Resources/en.lproj

This will process all .m, .h and .mm files in your directory hierarchy and create ".strings" files for them in the en.lproj directory (note, the en.lproj directory must already exist). This assumes that the localized resources directory you created is located at "Resources/en.proj", relative to your Project's root directory; obviously, you'll need to change this if your localized resources are elsewhere.

The ".strings" file will be filled with entries that look like this:

/* This comment provided comes from the last parameter of the NSLocalizedString macro. */
"Some UI string %@ to translate %@" = "Some UI string %1$@ to translate %2$@";

Your translator just needs to translate the right-hand side of the equality statement. Notice that placeholders in your strings are given ordinal positions (1 and 2 in this case) so that the translation can change the order of placeholders if necessary (obviously, if you use placeholders, you should include a comment that explains what they're going to be).

Localization versus Internationalization: generally, the whole process of creating new language variants is referred to as localization. In reality though, it comprises two steps:


1. Internationalization: where you decouple the program from the original locale
2. Localization: where you add translations and behaviors for each new locale

By that terminology, the inclusion of NSLocalizedString wrappers and the creation of ".strings" files is the "Internationalizing" phase.

genstrings will only handle static NSLocalizedString and CFCopyLocalizedString strings

The only strings that will be automatically extracted are those wrapped inNSLocalizedString[...] and CFCopyLocalizedString[...] macros. Obviously, all your user interface text needs to be wrapped in these but also remember that the underlying -[NSBundle localizedStringForKey:value:table:]method will not be automatically extracted.

Why would you ever use -[NSBundle localizedStringForKey:value:table:] directly then? The answer is for dynamically generated strings.

The genstrings command will raise an error if it detects anything other than a static string in the localization macros. This is appropriate because you don't want your translators translating variable names and function calls (they only need to translate the results of those calls).

The answer to why you would use -[NSBundle localizedStringForKey:value:table:] is then: the actual strings to be translated are located elsewhere in the code (or are in a ".strings" file that was not generated from code) and you are simply looking them up dynamically.

Encoding problems

From Mac OS X 10.5 onwards, you can put any UTF-8 characters in yourNSLocalizedString constants. Prior to this, they were required to be pure 7-bit ASCII with all Unicode escaped with \\Uxxxx style escaping or you could use MacRoman with the -macRoman command-line option to use MacRoman high-ASCII characters.

A quick swipe at almost everybody: UTF-8 has been around since 1993 and Unicode 2.0 since 1996; if you have created any 8-bit character content since 1996 in anything other than UTF-8, then I hate you.

I weep to think of the years of programmer time that are still wasted attempting to support non-Unicode formats without characters getting garbled because people are still creating content using ancient encodings without useful identifiers to indicate what nonsense encoding they're using (or worse, people creating content that explicitly uses the wrong encoding for an encoding-specific text field).

MacRoman? Atrocious. Big-5? I hope you want to see garbage output. Windows Latin? You suck. If you're creating new content using anything other than UTF-8, UTF-16 or UTF-32 then you should be forced to serve prison time with whatever idiot monkey decided that UTF-16 should be allowed little-endian and big-endian variants instead of a single authoritative encoding.

The actual text files generated by genstrings are UTF-16 in whatever byte order your system happens to use. i.e. UTF-16BE on PowerPC and UTF-16LE on Intel Macs.

Grumble.

Translating XIB files

Not all your strings will come from your code. The other common text location is in XIB files. XIB files can be a little bit trickier than strings in code due to two factors:

1. While you can extract the strings from a XIB file easily, you also have to merge them back in once the translation is complete — basically another step that can go wrong
2. The ".strings" file format extracted from XIB files is uglier and doesn't have easy room for comments to send to the translator

For these two reasons, I generally avoid putting text in XIB files if reasonably possible — it is normally easier to have text inserted at NIB load time by the code. Of course, menus, button labels and automator labels can't reasonably be moved into code so you're still likely to need a number of XIB files translated.

You extract the .strings from XIB files in a similar way to extracting the strings from code. However, first we must make all of our XIB files localizable (if they aren't already).

To localize your XIB files, select them all in the Xcode project Group Tree, Get Info on them and then from the first tab, select "Make file localizable".

Then, go to the localized directory where your files all ended up (if there's multiple, you'll need to do this for each one) and run the following in Terminal:

for file in *.xib; do
    ibtool --export-strings-file "$file".strings "$file"
done

This will generate all the ".strings" files for your XIB files.

Once the ".strings" files are localized, create a new ".lproj" directory with the appropriate language name for the new translations and put all the ".strings" files in it. Then open a Terminal in this new folder and run:

for file in *.xib.strings; do
    basename=`basename "$file" .strings`
    ibtool --strings-file "$file" --write "$basename" "../en.lproj/$basename"
done

This will merge all the ".xib.strings" files in the current directory with the XIB files from the en.lproj directory, creating the translated XIB files.

Translating other resources

The same "Make file localizable" step that we used for the XIB files in the previous section can be applied to any resource file in your Xcode group tree so you can localize other resources in whatever way is apppropriate.

Here's a tip though: avoid localizing anything other than strings and XIB files by whatever means possible. Having non-strings files for translation will cause you nothing but pain and suffering.

In particular: avoid localizing images. Work as hard as you can to keep all text out of images (except in logos that don't require translation). You can perform quite sophisticated drawing and text handling in Cocoa code if needed and this will almost always be easier than localizing images.

I haven't really touched on non-string code localization topics in this post. There's date, time, numbers, error descriptions and other stuff — most of the time, the classes and APIs for these make it clear what you need to do. Just read Apple's Internationalization documentation.

Conclusion

Most programmers should already know the information in this post. Numerous other Mac programming blogs have discussed the topic:

• Call Me Fishmeal: Pimp My Code, Part 17: Lost in Translations.
• OS X & Cocoa Writings: Internationalizing Cocoa Applications, by Andrew C Stone
• Internationalizing Cocoa applications, mmalcolm Crawford

See how anciently old those second two links are? I'm not telling you new information. The advice remains the same: always, ALWAYS useNSLocalizedString for your user interface strings.

Actual translation can happen later or not at all — my point is that your need for translation (or lack of need) should not determine whether you useNSLocalizedString as it is best practice in any case. Of course you can rest assured that translation will all work out if your code is alreadyNSLocalizedString-compliant.

+++++

Change Company Name from Within Xcode on a Per Project Basis

A common question for most anyone new to Xcode is how to change the Company Name that is added to each new source file. The default information looks similar to the following:

Copyright (c) 2010 MyCompanyName. All rights reserved.

Up until Xcode 3.2 to change this value you had to resort to running a command from a terminal, you can see how this was previously done in this tip: Change Company Name in Xcode.

A welcome change with 3.2+ is that this value can now be managed from within Xcode. Even better, the name can be configured on a project by project basis, which is really nice if you need to maintain multiple copyright statements across projects.

Change Company Name within Xcode

In the Groups and Files window, right click on the project name and select Get Info:

In the General Settings tab, near the bottom you’ll see a field for the Organization Name:

Update this field and the new value will be reflected in each source code file you create in the active project.

＊所有元素都负责显示自身。因此，有时会__weak所在layer的指针。 
@property (nonatomic, readwrite, assign) __weak CPTAnnotationHostLayer *annotationHostLayer; 
＊即使自己重写函数，也适用了@synthesize关键字。 
＊好像：setNeedsLayout不但让该layer重新layout，而且让其各个父layer也重新layout。

* globalYRange会影响到YRange的改变。因此，如果需要改变YRange，则要先将globalYRange设置为nil。 
pricePlotSpace.globalYRange = nil; 
[pricePlotSpace scaleToFitPlots:graph.allPlots]; 
pricePlotSpace.globalYRange = pricePlotSpace.yRange;

+++++