Kev

As of Tiger, a new NSDateFormatter has been introduced to Foundation, and within it are a few things that might take some getting used to. So I will outline the date formatter in its entirety, and how to understand how all of the pieces work together.There are two main modes, or behaviors, of the NSDateFormatter: Pre 10.4 and 10.4+ (these same labels are used in Interface Builder).

• Pre 10.4 Mode (NSDateFormatterBehavior10_0)
  This mode was the only mode until Tiger was introduced, and it makes use of the the strftime-style format strings. The strftime format identifiers look like “%S” (seconds), “%m” (month number), and “%d” (day of month) to just name a few. Actually, the documentation for these identifiers is accurately described in Apple’s documentation that comes with Xcode or is found online at the ADC website.

  UsageSo how might I go about creating a date formatter that exhibits the old Pre 10.4 behavior? Well, it’s actually quite simple. When you create your instance of NSDateFormatter, use the initWithDateFormat:allowNaturalLanguage: initializer, instead of the usual init method.You should note:Once you create the Pre 10.4 date formatter with a format string, you cannot change it. Though NSDateFormatter has a method setDateFormat:, it only applies to the new date formatter behavior. You can however, convert the date formatter to the newer behavior by calling setDateFormatterBehavior: and passing in NSDateFormatterBehavior10_4.

  Sample code

      NSDateFormatter *df = [[[NSDateFormatter alloc] initWithDateFormat:@"%1m/%1d/%y"
                                                      allowNaturalLanguage:YES]
                                                      autorelease];
      // The following code will print something like 2/11/2007. Also notice how
      // putting the '1' before the 'm' and 'd' in our format string took the padding
      // zeros away.
      NSLog(@"%@", [df stringForObjectValue:[NSDate date]]);
  

• 10.4+ Mode NSDateFormatterBehavior10_4
  Arguably the behavior you will want to use in your code is the 10.4+ Mode. This mode conforms to the Unicode TR35-4 standard, so it has a ton of features that the Pre 10.4 behavior just doesn’t have. For one, it uses different identifiers, the Unicode site at this link has all of the identifiers and how you can use them to construct date format strings. The documentation is mostly accurate except that though ICU claims three lower case e’s (”eee”) should evaluate to something like “Tues” or “Wed”, that isn’t reflected by the NSDateFormatter.

  Changing the date format string
  One of the really nice things about the new date formatter behavior is that you can set the date format string to something else after you create it. If you call setDateFormat: with some string, the changes are made immediately. This is nice if your date format string is dynamic.

  Date and Time Styles
  Another feature of the 10.4+ behavior is that you can tell it to ignore date format strings all together, and instead use the time styles defined by the user in System Preferences. These are set by each user on their own system in the International pane of System Preferences:
  

  You can set a date or time style such as short, medium, long, full, or none at all. The methods for doing this are setDateStyle: and setTimeStyle:. The tricky part about using these styles programmatically comes in the order that you call those methods. For example, if you call setDateStyle: or setTimeStyle:, it voids the effect of the date format string. However, if after calling setDateStyle: or setTimeStyle:, you set the date format string by calling setDateFormat:, it then voids the time and date styles you just applied. The general rule of thumb is that whatever you call last is what the date formatter uses. If you set the date or time style last, it uses that; if you set the date format string last, then it uses that. The code below illustrates these little quirks.

      // Create our date formatter and a sample date to work with
      NSDateFormatter *formatter = [[[NSDateFormatter alloc] init] autorelease];
      NSDate *date = [NSDate date];
  
      // This will produce a date such as "07/11/2007 22:15".
      [formatter setDateStyle:NSDateFormatterShortStyle];
      [formatter setTimeStyle:NSDateFormatterShortStyle];
      NSLog(@"%@", [formatter stringFromDate:date]);
  
      // This will produce a date such as "07/11/2007", notice, without the time.
      [formatter setTimeStyle:NSDateFormatterNoStyle];
      NSLog(@"%@", [formatter stringFromDate:date]);
  
      // This will produce a date such as "7 Nov 2007", thus nullifying the date
      // and time styles we set above.
      [formatter setDateFormat:@"d MMM yyyy"];
      NSLog(@"%@", [formatter stringFromDate:date]);
  
      // But now if I reset the date style, we nullify our date format string.
      // And though I didn't reset the time style, since I reset the date style,
      // the formatter assumes the use of both.
      [formatter setDateStyle:NSDateFormatterShortStyle];
      NSLog(@"%@", [formatter stringFromDate:date]);
  

The NSDateFormatter can be a tricky or intimidating class at first, but I think when you really unpack it, it is quite easy. Just remember:

• Two modes: pre 10.4 (strftime-style, NSDateFormatterBehavior10_0) and 10.4+ (Unicode, NSDateFormatterBehavior10_4).
• When using pre 10.4 behavior, use initWithDateFormat:allowNaturalLanguage: to create it. And remember, once you create it, you can’t change the format string.
• When using 10.4+ behavior, uses standard init to create it. You can use a date format string or the date/time styles. And when setting these, remember that the last method you call is the style it uses (date format string versus date/time styles).
• Check out the Apple and Unicode documentation for a complete list of identifiers.

I saw some code for an alternative way to store instance variables for a class (instead of just declaring them in the class’s header). I will show the code and then explain it:

@implementation NSObject(ExtraOutlet)

static CFDictionaryRef externalFooTable = NULL;

- (void)setFoo:(id)value {
     LazyInit(externalFooTable, ...); // This just initializes if externalFooTable is nil.
     if (value) {
          CFDictionarySetValue(externalFooTable, self, value);
     } else {
          CFDictionaryRemoveValue(externalFooTable, self);
     }
}

- (id)foo {
     return externalFooTable ? CFDictionaryGetValue(externalFooTable, self) : nil;
}

@end

OK, so what is going on here? Well, let’s say you have a class, and you have a instance variable called foo (and subsequent KVC methods). If you don’t use foo a lot, or if there are very few instances of your class that will have foo be something other than nil, than you can store the value of foo per instance in a static hash table. The key to the hash table per instance is the instance’s address (self in ObjC).

Because of this static hash table, if you have 1,000,000 instances of your class, and you only have one instance that has foo be something other than nil, than you are saving 3.815 MB of RAM! And imagine doing this for a complicated program with lots of classes and instances, you could really have a major performance boost.You can use this method on your own classes, or as the example suggests, add additional instance variables to classes you didn’t write like NSObject, NSString, etc.

Thanks co-worker Jon for teaching me this one.

I ran across what to me was not a seemingly obvious Cocoa artifact today. Let’s suppose that you create some strings much in the way I do below:NSString *myString1 = @"Kevin";NSString *myString2 = [[myString1 copy] autorelease];NSString *myString3 = [[[NSString alloc] initWithString:myString2] autorelease];NSLog(@"%p, %p, %p", myString1, myString2, myString3);Strangely, my log prints the following:0×6060, 0×6060, 0×6060meaning that all the objects are in the same address space! I didn’t quite understand how this could be considering the fact that I used three different methods to create a string. I tried the same thing with NSArray, NSIndexPath, and some others. Strange…After asking around, I finally got my response from Michael, a Cocoa veteran down the hall. He said, “try the same thing, but with mutable strings.”NSMutableString *myString1 = @"Kevin";NSMutableString *myString2 = [[myString1 copy] autorelease];NSMutableString *myString3 = [NSMutableString stringWithString:myString2];NSLog(@"%p, %p, %p", myString1, myString2, myString3);And sure enough:0xae60dd, 0xae60f7, 0xae60fd: different objects!So what’s the deal behind this? In Cocoa, when you allocated a new immutable string using any method, it checks to see if that string already exists in memory. If so, instead of actually allocating a new string, it just increments its retain count. You can imagine how handy that when you create 60,000 of the same string, and Cocoa just creates one with a retain count of 60,000.With mutable objects, however, we do not just bump the retain count because of the fact that if two sources create the mutable string “Kevin”, for example, and then one of the sources changes it to “Keeven”, they change in both places. Not a good thing. So mutable objects are actually allocated each time you create one.So watch out when you are doing pointer checking with immutable objects. You might not be getting exactly what you thought!