For a limited time, you can download install directly from http://web.me.com/z.gramana/blaze/.
You can still get the source from https://bitbucket.org/zgramana/sharpscript (although I’ll be moving the repository soon).

NOTE: If you have already installed SharpPad, you’ll need to install blaze from the location above in order to received auto-updates.

Most of us never bother to consider all this, but once you do, it makes sense. Just like the universe doesn’t care whether you are left-handed or right-handed, the .NET compiler doesn’t care whether you use var or not (with two exceptions noted below). It isn’t inherently worse or better. It’s utility depends on how you work best. For some, it cuts against the grain. For others, it cuts with the grain. If being a lefty is analogous to using var, then why are so many coders right-handed? I can’t say entirely, but I do believe it’s in part because nuns keep rapping the knuckles of developers when they opt to use it (ReSharper excluded).

I really only feel strongly about it because I think (a) it’s such a small thing that most people can’t be bothered to think much about it, and (b) as a result of (a), many people give too much credence to the opinions of “authorities” who weigh-in on the topic. I don’t want to rehash prior discussions on the topic, but I do want to distill down my view on the issue. Hopefully it will at least provide an entry point for some into even *having* a discussion. It’s okay to be use var. It’s not your fault.

So, I want to begin with laying out the standard arguments *against* using var (for anything other than anonymous types). I don’t want to attack straw men, here, so I’m trying to be accurate. Call me out if I miss my mark.

1. var makes code less readable. To determine a variable’s type when using var, I’m required either to apply the same type inference logic that the compiler uses, or become dependent on an IDE’s Intellisense/autocomplete feature.
2. var makes refactoring more difficult. To change the type of every MyClass variable, I just need to /MyClass/MyNewClass/g and I’m done; whereas with var I will miss instances where the type was inferred from the return type of a method call.
3. var makes debugging more difficult. Because of (1), there is a category of bugs that won’t be caught until runtime, and where the exception will not intuitively relate to the underlying problem.

Here are my counterarguments:

1. This depends on what you consider “readable”, and in general I find the first line more “readable” (especially if you also do a fair amount of javascript):

   // Don't lie: which variable name can you spot faster?
   
   // Focus my cognitive load only on the constructor call.
   var lookupTable = new Dictionary<String,Func<Int,MyClass>>();
   
   // Does the type declaration exactly match the constructor's class?
   // It's going to take some mental effort to see.
   Dictionary<String,Func<Int,MyClass>> lookupTable = new Dictionary<String,Func<Int,MyClass>>();
   
   // I also find using interfaces clearer when using vars as well.
   var instance = new MyRepository() as IRepository;
   // Instead of:
   IRepository instance = new MyRepository();
   // This doesn't help me if MyRepository 
   // actually implements IRepository<T>.
   

   Considering nobody wants to type that loooong type name twice, most mortals will rely on autocomplete to avoid typing the entire thing anyways, so there is no great disadvantage there to using var in the first place. I also find myself wanting to start abbreviate/shorten longer, but more descriptive, type names when I don’t use var quite so much. It just gets fatiguing, and feels like my own code is “getting in my way”. I’ll take ObservableCollection over ObsColl when reading someone else’s code (or my own, six months later).
   In addition, I believe you should know the compiler’s type inference rules, and should be applying them every time you do an assignment–regardless of the style you’re opting for. If you can’t readily make out the type on the right side of assignment operator (I’m looking at you, overly-complicated LINQ expressions), then you have a code smell and probably need to refactor (e.g. to a method group).

2. Take the following example:

   // Suppose:
   IRepository instance = Repository.Create(typeof(MyClass));
   // If I refactor MyRepository() to implement
   // the generic interface, I now have to refactor
   // my variable types as well. If I had just done:
   var instance = Repository.Create(typeof(MyClass));
   // Then I would be fine.
   

   I argue that using var avoids a DRY violation. In fact, I actually like the fact that I can refactor a method return type without changing the variable declaration. Instead of the compiler complaining about the variable name not matching, it skips straight to all of the places where the new contract differs from the old contract. Declaring the variable type doesn’t avoid this, it just adds an additional compiler error noise. In general, I find the when using var when I don’t have to, I am paying closer attention to contracts and variable names–just the things I should be paying attention to.

3. I’m not going to argue too much against the example raised in the linked article. It’s an edge case for me, and in general, I find this to not really be a problem. My first question would be “why is the compiler think the result is a long instead of an int?” This would be the exact question that I would ask myself if I got a the error message at compile-time instead of run-time.
   However, consider the following function f:
   

   Func<int> f = ()=>; 
   { 
       uint unsignedNumber = 42;
       int signedNumber = 10;
       var result = unsignedNumber * signedNumber;
       
       return result; 
   };
   

   Attempting to compile this snippet results in the following compiler errors:

   • Cannot convert lambda expression to delegate type ‘System.Func’ because some of the return types in the block are not implicitly convertible to the delegate return type
   • Cannot implicitly convert type ‘long’ to ‘int’. An explicit conversion exists (are you missing a cast?)

   So, this var “fail” is even more of an edge case than presented originally.

Soooo…

I am not so much seeking to win converts over to using var as I hope people will begin to see this is as, at least, a style and preference issue–and not as an issue of right or wrong. Do I prefer var? You betcha! Do I look down on those who don’t? No, I get it. I’m just too lazy to do all that typing. Honestly, I’d rather save my finger strength for more coding. Or even–GASP!–blogging.

Oh, and the caveats mentioned above?

• If you are writing code against 2.0, then you obviously can’t use var. If you are going back in forth between say, 2.0 and 4.0, then I can absolutely appreciate wanting your fingers to remember just the one way.
• If you are using anonymous types, or Linq, then you have to use var. Just like above, if you do a reasonable amount of either, then I can absolutely appreciate wanting your fingers to remember just the one way.

Perhaps I just have an outdated msysgit installation, perhaps it’s just a limitation of running git on win32, or perhaps my gitfu is just not l33t enough. Who knows. After many fails, though, this sequence of git bash commands is the only thing that works for me:

git clone https://github.com/<your_username>/<child_repo_name>.git
cd <child_repo_name>
git remote add upstream https://github.com/<parent_repo_owner_username>/<parent_repo_name>.git
git fetch upstream
git merge upstream/master
git push origin master

Using the git protocol over ssh seems to be a no-go, so I’m using HTTPS instead. Hopefully this solution works for you too.

If you’re on msysgit, and are having trouble working with github, I feel you. If not, or if you have a better solution, please post a comment and share.

Happy forking!

1. when someone else’s object doesn’t do what I want it to, and isn’t open for extension, or
2. when I want to pass an object to a method that wouldn’t accept the object otherwise.

However, decoration can be tedious, can violate the DRY principle, and can lead to lots of little wrapper classes lying around that just clutter a project up. What if we can prevent that?This is where a generic Wrapper<T> class would come in really handy. With one class, we could wrap not just one class, but any member of set of classes. While this is an interesting idea, we can anticipate some limitations. For one, we would be giving the same new capabilities to all of the wrapped classes. Unless we’re implementing a specific interface, that’s not something we need to do very often. We want to be able to add new members when we want to, and without having to create a new decorator class. The alternatives, like writing a ton of reflection code or emitting bytecode, introduce design-time and run-time overhead that reduce the potential convenience of our generic wrapper class. However, using .NET 4.0′s support for the Dynamic Language Runtime offers the missing piece of our puzzle.

The result: our Dynamic<T> class, presented below. The code shows an example of how you might choose to implement your own generic dynamic wrapper class. It uses reflection in some smart ways to give us the benefit of strong type-iness, while at the same time allowing us to go buck wild adding new properties and methods at runtime with reckless abandon. With just a little extra work, you can even implement ISerializable. Woo wooooo!

So, how does that help us with our two scenarios from before? Well, it can come in handy for Scenario 1 when you want to, say, serialize a class that isn’t marked with [Serializable]. It’s also handy for Scenario 2, where we want wrap an interface implementation around an object that doesn’t already support it. This gives us the ability to pass our original object to other methods that wouldn’t otherwise take them. In the example below, we’re writing a wrapper that allows our original object to comply with the DynamicObject contract. So, with that in mind, let’s get our code on:

// Copyright:     (C) 2011 by Zachary Gramana
// Author:        Zachary Gramana
// Version:       0.1
// Description:   Wraps any class inside of a DynamicObject.
// StartedOn:     7/20/2011
using System;
using System.Collections.Generic;
using System.Dynamic;
using System.Linq;
using System.Reflection;

namespace Utility.Types
{
    /// <summary>
    /// Wraps any object in a DynamicObject, but in a strongly-typed way.
    /// It also logs usage of the object to standard output.
    /// 
    /// Running:
    ///     dynamic item = new Dynamic<String>("Jabberwocky");
    ///     item = new Dynamic<AppDomain>(AppDomain.CurrentDomain);
    ///     item.SetData("Foo", "Bar");
    ///     item.GetData("Foo");
    ///     item.Foo = "Bar";
    ///     var bar = item.Foo;
    /// 
    /// Outputs:
    ///     Dynamic's Inherited Properties:
    ///             Chars
    ///             Length
    /// 
    ///     Dynamic's Inherited Properties:
    ///             DomainManager
    ///             CurrentDomain
    ///             Evidence
    ///             FriendlyName
    ///             BaseDirectory
    ///             RelativeSearchPath
    ///             ShadowCopyFiles
    ///             ActivationContext
    ///             ApplicationIdentity
    ///             ApplicationTrust
    ///             DynamicDirectory
    ///             SetupInformation
    ///             PermissionSet
    ///             IsFullyTrusted
    ///             IsHomogenous
    ///             Id
    ///             MonitoringIsEnabled
    ///             MonitoringTotalProcessorTime
    ///             MonitoringTotalAllocatedMemorySize
    ///             MonitoringSurvivedMemorySize
    ///             MonitoringSurvivedProcessMemorySize
    /// 
    /// Results:
    ///     Invoking instance.SetData() returned '(null)'
    /// 
    /// Results:
    ///     Invoking instance.GetData() returned 'Bar'
    /// 
    /// Results:
    ///     Setting instance.Foo = Bar
    /// 
    /// Results:
    ///     Getting instance.Foo returned 'Bar'
    /// 
    /// </summary>
    public class Dynamic<T> : DynamicObject
    {
        private static readonly Dictionary _propertyCache;
        private        readonly T          _instance;
        private        readonly Dictionary _propertyBag;
        
        /// <summary>
        /// Our type constructor. This populates our lookup store with
        /// all of the property information we need about the object
        /// we are wrapping. This runs just once, the first time
        /// we make an instance of the a particular type.
        /// </summary>
        static Dynamic()
        {
            _propertyCache = typeof(T)
                .GetProperties()
                .ToDictionary(
                    k => k.Name, 
                    k => (Object)k
                   );

            Console.WriteLine("\r\nDynamic's Inherited Properties:", typeof(T).Name);
            foreach (var prop in _propertyCache) 
            {
                Console.WriteLine("\t" + prop.Key);
            }
        }
        
        /// <summary>
        /// Our instance constructor.
        /// </summary>
        /// The object we are wrapping.
        public Dynamic(T instance)
        {
            _instance = instance;
            _propertyBag = new Dictionary(StringComparer.CurrentCulture);
            
            // Log this action.
            Console.WriteLine("\r\nCreated new {0} wrapper object.", this.GetType().Name.TrimEnd(new[] {'`','1'}), this.GetType().GetGenericArguments()[0].Name);
        }
        
        public override bool TryGetMember(System.Dynamic.GetMemberBinder binder, out object result)
        {
            Boolean value;

            Object prop;
            value = _propertyCache.TryGetValue(binder.Name, out prop);

            if (value)
            {
                result = ((PropertyInfo) prop).GetValue(_instance, null);
                value = true;
            }
            else
            {
                value = _propertyBag.TryGetValue(binder.Name, out result);
            }
            
            // Log this action.
            Console.WriteLine("\r\nResults:\r\n\tGetting instance.{0} returned '{1}'", binder.Name, result ?? "(null)");
            
            return value;
        }

        public override bool TrySetMember(SetMemberBinder binder, object value)
        {
            Object prop;
            var foundProp = _propertyCache.TryGetValue(binder.Name, out prop);
            
            if (foundProp)
            {
                ((PropertyInfo) prop).SetValue(_instance, value, null);
            }
            else
            {
                _propertyBag[binder.Name] = value;
            }
            
            // Log this action.
            Console.WriteLine("\r\nResults:\r\n\tSetting instance.{0} = {1}", binder.Name, value ?? "(null)");

            // You can always add a value to a dictionary,
            // so this method always returns true.
            return true;
        }
        
        public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
        {
            // Use reflection to get the method info.
            var method = typeof(T)
                .GetMethod(
                    binder.Name, 
                    args.Select(a => a.GetType())
                        .ToArray()
               );
            
            if (method == null) 
            {
                result = null;
                return false;
            }
            
            result = method.Invoke(_instance, args);

            // Log this action.
            Console.WriteLine("\r\nResults:\r\n\tInvoking instance.{0}() returned '{1}'", method.Name, result ?? "(null)");
            
            // If we didn't throw an exception, we succeeded.
            return true;
        }
        
        public T GetInstance()
        {
            return _instance;
        }
    }
}

JSON-Schema lets us do some cool things, like allowing more than one type to be valid for a given property. For example, I could allow a property to take, say, either a string or an integer. This is called a union type. Cool enough. But how could this help us with graph loading?

Consider something like this:

   "properties":{
       "MyManager":{
           "title":"MyManager",
           "type":[{"type":"string","pattern","(\w|-){22,24}"},"object"],
       }
   }

What I *really* want is the ability to do:

   "properties":{
       "MyManager":{
           "title":"MyManager",
           "type":["http://localhost/schemas/models/employee#/id","object"],
       }
   }

Either way, it’s a handy trick to add in your collection.

To bring that simplicity to your browser, just paste the following into the URL field of a manually created bookmark:

javascript:(function(){c=prompt("Enter the fully-qualified name of a class, method, property, etc.:","System.Object");window.location="http://msdn.microsoft.com/en-us/library/"+c+"(v=VS.100).aspx"}());

The intrepid code will most likely try the DefaultValueAttribute next, and end up with something like.

[DefaultValue(5)]
public int FavoriteNum
{
    get { return Record.FavoriteNum; }
    set { Record.FavoriteNum = value; }
}

And, regrettably, this doesn’t work.

Our intrepid coder now scours the documentation and discovers the .WithDefault() method buried in the migrations code:

        public int Create()
        {
            SchemaBuilder.CreateTable("MyPartRecord", table => table
                    .ContentPartRecord()
                    .Column("FavoriteNum", c => c.NotNull().WithDefault(5))
                );
        }

Euphoria runs high, as the database does indeed construct the proper default constraint. Woo hoo! Except that Orchard doesn’t pass null to this value, it always gets 0. The wave of euphoria comes crashing down on the rocky shores of reality. Sad trombones lament your misfortune.

Don’t worry, you still have options. If your model class inherits from a class derived from ContentPart<TPartRecord>, all you need to do is initialize your value in TPartRecord‘s constructor. For example, assume MyPart inherits from ContentPart:

public class MyPart : ContentPart<MyPartRecord> {
	public int FavoriteNum {
		get { return Record.FavoriteNum; }
		set { Record.FavoriteNum = value;}
	}
}

public class MyPartRecord : ContentPartRecord {
	public MyPartRecord() { FavoriteNum = 5; }
	public virtual int FavoriteNum { get; set; }
}

But what if your model class inherits from ContentPart instead? The ContentPartclass lives in the Orchard framework, and so we aren’t able to use the above technique. If you’ve been down this road, then you know it feels like a dead-end. We’re in luck, though. Our solution comes via the event hooks that are exposed by deriving a class from ContentHandler. In particular, we need to pass your default-value-setting code to the OnInitializing method. Here is an example part handler class that finally does what we’ve been trying to do:

using System;
using System.Collections.Generic;
using Orchard.ContentManagement.Handlers;
using Orchard.Data;
using Contrib.MyModule.Models;

namespace Contrib.MyModule.Handlers
{
    public class MyPartHandler : ContentHandler
    {
        public MyPartHandler(IRepository repository)
        {
            Filters.Add(StorageFilter.For(repository));
            OnInitializing((context, part) => {
                part.FavoriteNum = 32;
              });
        }
    }
}

And there was much rejoicing. Happy coding!

This sample code will compile, and run, and fail oh-so-epically:

using System;

namespace VirtualSpike
{

    class Program
    {
        // Internal static field.
        private static dynamic _singleton;
    
        // Singleton manager.
        public static dynamic YourFateSingleton<T>(T myT)
        {
            if (myT == null)
            {
                _singleton = default(T);
                return _singleton;
            }
            else
            {
                return _singleton;
            }
        }
        
        static void Main(string[] args)
        {
            var fate = Program.YourFateSingleton(DateTime.Now);
            Console.WriteLine("You will become fabulously rich at");
            Console.WriteLine("this exact date and time: {0}", fate);
        }
    }
}

Can you figure out why? (I’ll give you a hint: read section 12.9.4.3 of Jeffrey Richter’s “CLR via C#”)

(spoiler ahead)

If you suspect that the answer has something to do with the way the CLR implements generics, then you would be right. The CLR gives us the ability to filter our type variable, T, so that only specific set of types are eligible to become T. This is very important feature of the CLR’s generic implementation, and sets it apart from other languages.

When a generic method is not provided with a filter, both value types and reference types are permissible as values for T. This fact allows us to pass a DateTime object, which is a value type (viz., a struct), to our singleton’s factory method. Unfortunately for us, even though the runtime will never evaluate the null check, the C# compiler will not even so much as throw up a warning or an information message. As a result, our singleton will (silently) never get initialized for our DateTime parameter.

Hopefully, someday, the C# compiler team will break on the same error as it does for trying to set myT to null, or at least return a warning. Until then, be sure to set the filter to where T: class or avoid null checks in unfiltered generic methods.

This solution is a great step forward when we need to invoke something like [myObj setCharacter:@"The Doctor" currentActor:@"Matt Smith"]. But what if we have a bunch of methods that don’t take objects? Wrapping them all in NSValues begins to really litter-up the code, and is frankly a bit tedious. And what if one want to invoke something like [myObj setCharacter:@"The Doctor" favoriteActors:@"Tom Baker", @"David Tennant", @"Matt Smith"]? There has to be a cleaner way, right? Behold! There is, and the answer lies in the somewhat obscure-ish va_arg macro. Now we can save the world from our unwieldy code. Allons-y!

We are already familiar with methods that take a nil-terminated list of arguments. For example, NSArray offers its arrayWithObjects: method. We know that we can pass a list of comma-separated objects to this method, so long as the list ends with a nil.

Hmm…wouldn’t it be handy if we could do the same thing with our own method? Enter the va_list.

Let’s begin with our method’s definition in our header file. We need some way of letting the compiler know that we don’t know just how many arguments arguments to expect ahead of time. Apple’s documentation for NSArray use the ellipsis, that is three periods in a row without spaces. That’s not just a mere convention that prose writers use. It’s actually a symbol that the compiler understands to mean a nil-terminated list. Molto bene! Now our method definition looks something like:

- (void)performSelector:(SEL)aSelector withContext:(void *)context, ... ;

To invoke a method on another thread, we went from:

• [myObj performSelector:@selector(setActorCount:role:) withContext:[NSArray arrayWithObjects: [NSValue valueWithBytes:&doctorCount objCType:@encode(int)], @"The Doctor", nil]] (yikes!)

to:

• [myObj performSelector:@selector(setActorCount:role:) withContext:(int *)doctorCount, @"The Doctor", nil]

That’s more like it! Notice how our simplified method signature is also much easier to deal with when debugging? That alone makes the change worth while. So now that we’ve settled that, let’s take a look at our revised method’s implementation:

- (void)performSelector:(SEL)aSelector
			 withValues:(void *)context, ...
{	// See if we were even passed any context.
	if (context)
	{
		// We'll need an NSInvocation, since it lets us define arguments
		// for multiple parameters.
		NSMethodSignature *theSignature = [self methodSignatureForSelector:aSelector];
		NSInvocation *theInvocation = [NSInvocation invocationWithMethodSignature:theSignature];
		[theInvocation retainArguments];

		// Now for the real automagic fun!  We will loop through our arugment list,
		// and match up each parameter with the corresponding index value.

		// Since Objective-C actually converts messages into C methods:
		NSUInteger argumentCount = [theSignature numberOfArguments] - 2;

		[theInvocation setTarget:self];			// There's our index 0.
		[theInvocation setSelector:aSelector];	// There's our index 1.

		// Use the va_* macros to retrieve the arguments.
		va_list arguments;

		// Tell it where the optional args start.
		// Since the first parameter, the selector
		// Isn't optional, tell it to start with 'context'.
		va_start (arguments, context);

		// Now for arguments 2+
		NSUInteger i, count = argumentCount;
		void* currentValue = context;
		for (i = 0; i < count; i++)
		{
			// If we run out of arguments, then we pass nil
			// to the remaining parameters.
			[theInvocation setArgument:&currentValue atIndex:(i + 2)]; // The +2 represents self and cmd offsets
			currentValue = va_arg(arguments, void*); // Read the next argument in the list.

			// We should also handle the case where we have
			// *more* arguments than parameters.  This will
			// let us cover cases where we are invoking
			// other variadic methods (like arrayWithObjects:).
		}

		// Dispose of our C byte-array.
		va_end (arguments);

		// That's it! (For configuring our NSInvocation).
		// In this example, we are going to invoke all
		// methods on a custom worker thread.
		NSThread *customWorkerThread = [EBCustomThread sharedCustomThread];

		// Invoke on our custom worker thread.
		[theInvocation performSelector:@selector(invoke) onThread:customWorkerThread withObject:nil waitUntilDone:NO];

		// Our NSInvocation is already autoreleased, so we're done.

	} else {
		// Since we were not given any context arguments,
		// just do a non-blocking invocation on a background thread.
		// We really would want to check to see that the selector
		// is valid, takes no arguments, etc., but that is left
		// as an exercise for the reader.
		[self performSelectorInBackground:aSelector withObject:nil];
	} 
}

So there you have it.

[Update: Doug, the lead over at the the Zoosk.com mobile dev, has taken the time to add the above method as a category on NSObject as part of the their very useful ZSFoundation library. Big thanks to Doug and his team for sharing!]

If you are interested in more threading tricks, check out these other fine articles:

• Matt Gallagher’s article “Construct an NSInvocation for any message, just by sending”.
• Dave Dribbin’s blog post “Invoke on Main Thread“
• Gabriel Handford’s post “Invoking Forward.”

Happy threading!

For the impatient among us, I’ll just list out the fonts available as of iPhone OS version 3.1.3 below. If you would rather learn how to fish, as it were, then here’s a quick method of determining the available font names yourself:

NSArray *fontFamilyNames = [UIFont familyNames];

for (NSString *familyName in fontFamilyNames)
{
	NSArray *fontNames = [UIFont fontNamesForFamilyName:familyName];
	for (NSString *name in fontNames)
	{
		// Do your font-y stuff here.
		NSLog("%@", name);
	}
}

Nice, eh?

Now, as promised, the font names available on the iPhone OS on version 3.1.3, organized by family:

• AppleGothic
  • AppleGothic
• Hiragino Kaku Gothic ProN
  • HiraKakuProN-W6
  • HiraKakuProN-W3
• Arial Unicode MS
  • ArialUnicodeMS
• Heiti K
  • STHeitiK-Medium
  • STHeitiK-Light
• DB LCD Temp
  • DBLCDTempBlack
• Helvetica
  • Helvetica-Oblique
  • Helvetica-BoldOblique
  • Helvetica
  • Helvetica-Bold
• Marker Felt
  • MarkerFelt-Thin
• Times New Roman
  • TimesNewRomanPSMT
  • TimesNewRomanPS-BoldMT
  • TimesNewRomanPS-BoldItalicMT
  • TimesNewRomanPS-ItalicMT
• Verdana
  • Verdana-Bold
  • Verdana-BoldItalic
  • Verdana
  • Verdana-Italic
• Georgia
  • Georgia-Bold
  • Georgia
  • Georgia-BoldItalic
  • Georgia-Italic
• Arial Rounded MT Bold
  • ArialRoundedMTBold
• Trebuchet MS
  • TrebuchetMS-Italic
  • TrebuchetMS
  • Trebuchet-BoldItalic
  • TrebuchetMS-Bold
• Heiti TC
  • STHeitiTC-Light
  • STHeitiTC-Medium
• Geeza Pro
  • GeezaPro-Bold
  • GeezaPro
• Courier
  • Courier
  • Courier-BoldOblique
  • Courier-Oblique
  • Courier-Bold
• Arial
  • ArialMT
  • Arial-BoldMT
  • Arial-BoldItalicMT
  • Arial-ItalicMT
• Heiti J
  • STHeitiJ-Medium
  • STHeitiJ-Light
• Arial Hebrew
  • ArialHebrew
  • ArialHebrew-Bold
• Courier New
  • CourierNewPS-BoldMT
  • CourierNewPS-ItalicMT
  • CourierNewPS-BoldItalicMT
  • CourierNewPSMT
• Zapfino
  • Zapfino
• American Typewriter
  • AmericanTypewriter
  • AmericanTypewriter-Bold
• Heiti SC
  • STHeitiSC-Medium
  • STHeitiSC-Light
• Helvetica Neue
  • HelveticaNeue
  • HelveticaNeue-Bold
• Thonburi
  • Thonburi-Bold
  • Thonburi

As you may have noted, several of the fonts are intended for non-Latin alphabets. They still include Latin glyphs, but they’re fairly bland sans-serif designs.

Still with me?  Then let’s dig in!

There are many areas where things can go wrong. Since the NSNetService instance provided to your delegate methods is autoreleased, you need to retain it if you plan on reusing it out of scope for that method. Most people will add it to an NSMutableArray or NSMutableDictionary so that it is automatically retained, and only autoreleased when removed from the collection. If that is the case for your code, make sure that you have properly initialized your collection before adding the object. Since messages to nil are perfectly ok, you may be sending the addObject:netService message to nil.  You will not receive an obvious indication that you never initialized your array or dictionary, and it will appear as though everything is working just fine…except that delegate messages “mysteriously” don’t fire off when peers change status, when you try to connect to one, etc. This crops up often enough in Bonjour troubleshooting that I would recommend it as the first place to start your troubleshooting.  It happens to the best of us. Let’s look at some code that illustrates the problem.

This code might look good first blush, but it will result in the “net service stops sending delegate messages” problem:

//////////////// Header ///////////////////////////////
# pragma mark -
# pragma mark Class Header

#import <UIKit/UIKit.h>

@interface MyNetController : NSObject
{
		NSMutableArray *_peers;
		UITableView *_peerListTableView;
}

/////////////// Property Declarations /////////////////
@property (nonatomic, assign) NSMutableArray *peers;
@property (nonatomic, assign) UITableView *peerListTableView;
@end

/////////////// Body //////////////////////////////////
# pragma mark -
# pragma mark Class Implementation

@implementation MyNetController

@synthesize peers = _peers;
@synthesize peerListTableView = _peerListTableView;

- (id) init
{
	self = [super init];
	if (self != nil)
	{
		self.peers = [NSMutableArray array];
	}
	return self;
}

- (void)netServiceBrowser:(NSNetServiceBrowser *)netServiceBrowser
		   didFindService:(NSNetService *)netService
			   moreComing:(BOOL)moreServicesComing
{
	// Resolve the service to get our peer's name.
	[netService resolve];

	// Add the object to our collection so that
	// it gets retained for future use.
	[_peers addObject:netService];

	NSLog(@"Found a new peer.  Resolve started...");
}

- (void)netServiceDidResolveAddress:(NSNetService *)sender
{
	// Peer will never show up in our table view.
	[_peerListTableView reloadData];

	NSLog(@"This line will never get printed.");
}

@end

If you haven’t spotted it already, the problem lies in line 32.  It assigns an array to the peers property that will fall out of scope as soon as init returns.  As a result, our debug console will show “Found a new peer. Resolve started…” and that’s it.  We will never get a callback to netServiceDidResolveAddress:, since netService was autoreleased after netServiceBrowser:didFindService:moreComing: fell out of scope. We can fix the problem, in this case, by changing the assign symbol to retain on line 14. Now our console output will show ”This line will never get printed” and our table will reload as expected.

Some other common issues you might want to watch out for:

• Make sure that your Application Protocol Name conforms to the RFC specifications:
  “[There may] be no more than fourteen characters (not counting the mandatory underscore), conforming to normal DNS host name rules: Only lower-case letters, digits, and hyphens; must begin and end with lower-case letter or digit.”
• Use @"" instead of @"local." for the domain when using NSNetService.  From Apple’s Bonjour FAQ:
  “If you pass an empty string (“”), then Mac OS X will automatically do the right thing. In Mac OS X 10.2 and 10.3, it will register using just link-local multicast. Starting in Mac OS X 10.4, it will automatically register your service in a user-chosen unicast DNS domain as well, if applicable. You only need to pass a specific string if you have some particular reason to want to register in some specific remote domain.”
• Bonjour does not allow for duplicate service names in the same domain. NSNetService can automatically handle this case by appending ” 2″ at the end of the name of the service instance.  However, this will not be the case if you are manually setting the service name.  Make sure that you write an error handler for name collisions in your netService:didNotPublish: method if you are passing something other than nil as the name parameter of initWithDomain:type:name:port.
• The OS X mDNS responder limits how frequently you can update your TXT record.  If your TXT record update rate exceeds 10 updates per minute, it will begin to introduce progressively longer delays before sending them.  The mDNS responder will print a line similar to the following in the system.log (which you can view in XCode):

Mon Aug 24 11:03:40 unknown mDNSResponder[16] <Error>: Excessive update rate for tester._my-app._tcp.local.; delaying announcement by 3 seconds.

• Bonjour/NSNetServiceBrowser on the iPhone/iPod Touch will utilize both Wifi and Bluetooth for service discovery–at least on supported devices. Each time you begin browsing for services, it will search both WiFi and Bluetooth (which you can verify the log messages in the iPhone’s Console, in Organizer). Since your Simulator “device” cannot use Bluetooth, your iPhone discovers it over WiFi. However, if you are using NSNetService or GKSession to publish on your iPhone, then you are publishing over both WiFi *and* Bluetooth as well (if your model supports it and  Bluetooth is enabled). NSNetServiceBrowser and GKSession, when running on BT-capable hardware, will dutifully find that both instances, and report both via delegate callbacks.
• NSNetService and GKSession will attempt to advertise on all network interfaces that are administratively up. If you see multiple instances of the same peer, and you are using NSNetService, this may be why. To prevent that from happening, stop resolving the service once the first result comes back. In other words, in your - (void)netServiceDidResolveAddress:(NSNetService *)sender method, include [sender stop]. This should prevent your code from getting this delegate message more than once for the same peer.
• Bluetooth PAN setup takes longer than publishing via Wifi, so the BT-discovered services will sometimes show up well after all the Wifi-based services have been discovered and resolved. When testing two real devices, I’ve even seen both services show up in my UI (usually only after the other phone crashes).  This primarily holds true for NSNetBrowser.  I haven’t come across it yet with GKSession, though I’ve spent less time working with GameKit.  This delay does make for some frustrating coding. If you are not using GameKit, your best bet is to utilize netService:didNotResolve: to either (a) retry resolution (maybe after a timeout), or (b) invalidate the netService instance and wait for the other phone to relaunch their app.
• If you are using multiple threads, make sure that your NSNetService gets scheduled into an actively running runloop and one that is running in default or common modes.

As an aside, there is an open bug filed with Apple whereby every so often, a normal Bonjour update will not result in a delegate method getting fired. I have only observed this occurring on a 3GS doing the monitoring. This can result in your app slipping out of sync with the network, despite the code doing everything right.  For example, a player may show a custom TXTRecord value of “available” when they actually are “busy.”  You can diagnose this fairly readily.  Trying periodically updating the TXTRecord on a test device. If every so often one peer shows the status as “available” while the rest show show “busy,” especially if device in err is a 3GS, then you probably have encountered it (assuming each one is running the same build).

NSNetServiceBrowser should consistently notify its delegate whenever a service begins/ends advertising on the network (under nominal conditions). The bug above is only an intermittent one, and apparently, hardware specific. If you see it occurring consistently, then it’s likely that your app is the real culprit.  One easily missed problem for apps running network code on a background thread: throwing an un-handled exception on that thread. This can occur without crashing your whole app due to Cocoa/Unix’s rules on threading. If your networking code “just stops working for no reason,” then you may want to check your iPhones Console and logs for error messages. Make sure you have set a breakpoint on the objc_exception_throw symbol.

Here’s another troubleshooting technique that I’ve found invaluable: monitor Bonjour broadcasts on your dev workstation via Terminal using the dns-sd command (see below). This will let you see all comings and goings on your local network for your service. If your app quits, but dns-sd does not show a Remove event, then your code needs revisiting. If dns-sd shows a remove event, but one your other apps instances doesn’t fire a delegate event then you may be seeing the above mentioned bug. It may also be the case that your code isn’t doing what you think it’s doing. And remember, this will only help you troubleshoot Wifi-to-Wifi service Bonjour. Bluetooth-to-Bluetooth (PAN) networking is not supported from iPhone Simulator.

Here is how you use that handy command:

dns-sd -B _serviceName
dns-sd -L Tester _serviceName._tcp.

Where  serviceName is a string that identifies your Bonjour service (like “my-app”).  Don’t omit the initial underscore (e.g. “_my-app”). Replace “Tester” with the display name/service name for a particular instance (e.g. “Player 1″).  The first line shows how to display the activity of all Bonjour peers advertising your service on your network segment.  It will let you know when each peer first appears and last disappears.  It provides a timestamp each time, which can really help in correlating events among multiple peers–perfect for debugging.  If you want to watch the activity of a single peer, including monitoring the status of all TXTRecord key/value pairs, then use syntax of line 2.  This will let you know if code updates to the TXTRecord dictionary actually get written to the network (as it were).

Flaggin’ It Down

If you spend any time using the dns-sd tool, you may wonder what the “Flags” column of its output means. There isn’t much documentation on this, so I had to dig through the source code to find out for sure. So that you don’t have to do the same thing, here’s what they mean (at least, when you use dns-sd for browsing published services):

• 0 = REMOVE entry message (0).
• 1 = REMOVE entry message (0) plus MORE TO COME message (1).
• 2 = ADD entry message (2).
• 3 = ADD entry message (2) plus MORE TO COME message (1).

You may suspect, at some point, that your network may be causing problems for your application. One technique I would recommend in order to determine that for sure: setup an ad hoc WiFi network between your Mac and your iPhone. This eliminates your wireless access point as a source of error. Just make sure that all other network connections on your Mac and iPhone are disabled first.  For example, unplug any physical Ethernet cables on your Mac, and disable Bluetooth on your iPhone.  That way GKSession will be working with just the WiFi interfaces. This setup has the added advantage of letting you build/test/debug while flying over 10,000 feet!  It also lets you write and test networking code, either Foundation networking or GKSession, using just the Simulator and your device.

Finally, don’t forget to test your code with real-world WiFi networks.  There are a number of factors that may be present in a network that causes trouble for your application. Public hot spots increasingly prevent individual WiFi clients from communicating with each other on same subnet (often referred to as “isolation”).  In addition, some will quarantine a network client until the user clicks through a “Terms of Service” web page. It does no good to develop an app that runs great in a lab environment, but breaks for your customers.  In fact, you may not even make it through the approval process.  If you don’t have a Q/A department with a huge testing lab at your disposal, just visit a few places with free public hot spots (e.g. Starbucks, McDonald’s, most coffee shops, hotels, big airports, etc), connect up with two or three test devices, and fire up your app on each.  This will give you an idea of how your code works in heterogenous environments.

I hope you find something helpful in these notes as you debug your code. This was kind of a brain dump, so I hope some of it made some sense. And please feel free to add your own notes in the comments section.

Happy Coding!

Excited with the possibilities, you dive in. You quickly have your Settings.bundle added to your project and your settings menus built. It all looks impressive, and only took a few hours. Woo hoo! You launch your app to watch this sorcery in action, when—bang! The app crashes. Not cool. A little debugging shows that the defaults you created on the root page work fine, but only if you open the your app’s Settings page before launching the program. And child menus have the same problem, except that users have to navigate to each child menu before the defaults work. You imagine the reaction you’ll get when you explain this to your users: I have to do whaaaat?

No worries, though. This gap in expectations has been well discussed on teh intertubes. In addition, Apple does provide a reference implementation in the AppPrefs project. However, the AppPrefs project only really points you in the right direction. The other two implementations, which extend the AppPrefs example, are a little too complex for my taste. In addition, none of these three take advantage of one of NSUserDefaults cooler features: defaults domains. When we code along in our app, we don’t want to worry about whether or not a user default has already been “initialized.” We want to put things in our Settings.bundle plists and have them Just Work.

To do that, we need to do a few things. We should really register our defaults before we do anything else. That means it should go in our UIApplicationDelegate’s applicationDidFinishLaunching: method, right at the top.

Second, we need to submit a dictionary of all default values to the standardUserDefaults singleton. It will put them in the Registration domain, which is separate from where your user’s overrides are kept. The registration domain only exists in memory, so we must recreate it every time we run the app. When you request a key value from NSUserDefaults, it will first look for a user-supplied value. If it can’t find one (in memory or on disk), it will look to the values in the Registration Domain, and return that one. That means we need to register all of the values included in our Settings.bundle property lists, whether we think we’ll need them or not. Make no assumptions. Sooner or later, we will (and if we don’t, then we should pull them out of the .plist). This also requires us to load the .plist file on disk for each child pane (if you have any).

If you think about this system for a bit, though, it does make sense. We are already storing the defaults in our .plists. Why store a duplicate copy in the NSUserDefaults application domain database? By not doing so, we avoid the need for synchronization, conflict resolution, etc. We only store the user-specified values in our app’s user defaults. That’s why our keys return nil, unless either we first register defaults, or unless the user manually sets the values (which opening the relevant Settings pane does). Why not have NSUserDefaults automatically registerDefaults like we do below? Well, I’m not sure. You could always submit a feature request to Apple.

In the meantime, then, here is my solution to add to the mix:

/** Loads user preferences database from Settings.bundle plists. */
+ (void)initSettingsDefaults
{
	NSUserDefaults *standardUserDefaults = [NSUserDefaults standardUserDefaults];

	//Determine the path to our Settings.bundle.
	NSString *bundlePath = [[NSBundle mainBundle] bundlePath];
	NSString *settingsBundlePath = [bundlePath stringByAppendingPathComponent:@"Settings.bundle"];

	// Load paths to all .plist files from our Settings.bundle into an array.
	NSArray *allPlistFiles = [NSBundle pathsForResourcesOfType:@"plist" inDirectory:settingsBundlePath];

	// Put all of the keys and values into one dictionary,
	// which we then register with the defaults.
	NSMutableDictionary *preferencesDictionary = [NSMutableDictionary dictionary];

	// Copy the default values loaded from each plist
	// into the system's sharedUserDefaults database.
	NSString *plistFile;
	for (plistFile in allPlistFiles)
	{

		// Load our plist files to get our preferences.
		NSDictionary *settingsDictionary = [NSDictionary dictionaryWithContentsOfFile:plistFile];
		NSArray *preferencesArray = [settingsDictionary objectForKey:@"PreferenceSpecifiers"];

		// Iterate through the specifiers, and copy the default
		// values into the DB.
		NSDictionary *item;
		for(item in preferencesArray)
		{
			// Obtain the specifier's key value.
			NSString *keyValue = [item objectForKey:@"Key"];

			// Using the key, return the DefaultValue if specified in the plist.
			// Note: We won't know the object type until after loading it.
			id defaultValue = [item objectForKey:@"DefaultValue"];

			// Some of the items, like groups, will not have a Key, let alone
			// a default value.  We want to safely ignore these.
			if (keyValue && defaultValue)
			{
				[preferencesDictionary setObject:defaultValue forKey:keyValue];
			}

		}

	}

	// Ensure the version number is up-to-date, too.
	// This is, incidentally, how you update the value in a Title element.
	NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleVersion"];
	NSString *shortVersion = [[[NSBundle mainBundle] infoDictionary] objectForKey:@"CFBundleShortVersionString"];
	NSString *versionLabel = [NSString stringWithFormat:@"%@ (%d)", shortVersion, [version intValue]];
	[standardUserDefaults setObject:versionLabel forKey:@"app_version_number"];

	// Now synchronize the user defaults DB in memory
	// with the persistent copy on disk.
	[standardUserDefaults registerDefaults:preferencesDictionary];
	[standardUserDefaults synchronize];
}

It’s important to remember the difference between the Registration Domain, and the Application Domain.

The general process is:

1. Create a “myDefaults” dictionary.
2. Load a .plist file into a dictionary.
3. Copy only your default key/object pairs into “myDefaults.”
4. Repeat (2) and (3) for each .plist in your Settings.bundle.
5. “Register” your defaults using registerDefaults: by passing it your “myDefaults” dictionary.
6. Synchronize.

When you perform step 5, NSUserDefaults will create a separate domain for your key/object pairs in myDefaults. If a search of user-supplied values (a.k.a. the Application Domain) for your key turns up nil, NSUserDefaults then search for that key in the Registration Domain.

Let’s walk through an example.

Assumptions:

• Your Root.plist includes “app_player_name” and a default value of “Player 1″
• Your Root.plist includes “app_game_difficulty” and a default value of “Easy”
• The user has overridden “app_game_difficulty” and set it to “Hard”

Scenario 1:

myPlayerName = [[ NSUserDefaultsstandardUserDefaults] objectForKey:@"app_player_name"]

 myGameDifficulty = [[ NSUserDefaultsstandardUserDefaults] objectForKey:@"app_game_difficulty"]

myGameDifficulty == @"Hard"
myPlayerName == @"Player 1"

NSUserDefaults searches the application domain for @"app_game_difficulty", and returns @"Hard". Now, if it had searched the registration domain, it would have found @"Easy". However, since the user-supplied value takes priority over the registered default, it still returns @"Hard".

Scenario 2:

Now, if had not registered any defaults in Scenario 1, this is what we would have ended up with instead:

myGameDifficulty == @"Hard"
myPlayerName == nil

Why? Because the user-supplied value of @”Hard” was stored in the Application Domain. It didn’t matter that the Registration Domain was empty. Since there was neither a user-supplied value in the Application Domain or a registered value in the Registration Domain, myPlayerName returned nil.

The key here is to remember that setting a default value, and registering a default value are two very different things.

Happy, er, Defaulting!

I plugged a couple of leaks that sprang up, but I still could not figure out why object allocations were growing to infinity (albeit at a snail’s pace). I could launch my app and just let it sit idle and CALayer objects were just proliferating. I narrowed the problem down to a simple background [UIView animation] block. Surely Core Animation didn’t leak, right?

Turns out, the answer is: not really. Thanks to Apple Devforum poster Rincewind, we now know:

You are probably seeing a bug in ObjectAlloc. You can confirm this in one of two ways

1) Examine the memory address of these “leaked” objects – they will probably all be the same (or a small set of addresses).

2) Add the Memory Monitor instrument from the library and watch your application’s Real Memory – this is generally a far better indicator of how much memory your application is using in total anyway.

Sure enough, he was right! The objects pouring into the list on Instruments all clustered around the same few memory addresses. Watching the physical memory confirmed that, despite the ever-growing heap in Object Allocations, physical memory was holding steady.

Whew! But Grrr! Hopefully you can avoid the frustration (until it’s patched).

Happy Debugging!

You can see glimmers of hope, though, as you study the problem.  Objective-C allows you to include multiple parameters in a selector, as in @selector(myMethod:withAValue:andAnother:). However, you will throw an exception at runtime since you can only specify one context object, and thus, the runtime will only have values to pass for one of the arguments. So close, and yet, so far away.  Is our only other option subclassing NSThread?  Thankfully, no.  We can have our cake and eat it, too, with just a little work on our part. The answer lies in the NSInvocation class.
 Huh? Invocation? The Apple developer class reference explains the idea succinctly:

An NSInvocation is an Objective-C message rendered static, that is, it is an action turned into an object … An NSInvocation object contains all the elements of an Objective-C message: a target, a selector, arguments, and the return value. Each of these elements can be set directly, and the return value is set automatically when the NSInvocation object is dispatched.

Oooh.  Clever.  Now the class name makes more sense. Instead of invoking of an object’s method using source code (at design time), we take a different approach.  We use an object to invoke another object’s method (at runtime).  Here, Objective-C shows us just how powerful introspection can be. Now that we have NSInvocation, how do we get back to spawning off arbitrary methods with multiple parameters? We create our own convenience method.  Let’s look at an example:

/** Calls arbitary methods inside of a new thread. */
- (void)performSelector:(SEL)aSelector withContext:(id)context
{
	// Before we get ahead of ourselves, let's do some
	// sanity checking on the context object pass
	// to the method.
	NSInvocationOperation *theOperation ;
	if ([context isKindOfClass:[NSArray class]])
	{
		// The docs explicity tell you not to use alloc/init,
		// but instead, use the class method invocationWithMethodSignature,
		// which takes a selector and returns its method's signature.
		NSMethodSignature *theSignature =
			[self methodSignatureForSelector:aSelector];

		// With our signature in hand, we can now call our
		// class method, which returns a usable (and autoreleased)
		// NSInvocation instance.
		NSInvocation *theInvocation =
			[NSInvocation invocationWithMethodSignature:theSignature];

		// Now for the real automagic fun!  We will loop through our context array,
		// and match up each parameter with the corresponding value
		// passed to us in our array.  First we will check to see if the there
		// are the same number of parameters and argument values (always nice).
		// Since we know context is a kind of NSArray, we cast it as one.
		NSArray *parameterValues = (NSArray *)context;
		NSUInteger parameterCount = [parameterValues count];

		// Objective-C actually converts selectors into C methods, and
		// some of that behind-the-scenes chicanary will affect us here.
		// To get an idea of how, let's look at the official guidance:

	      /* From SDK Docs:

		 NSInvocation Class Reference ...
		 There are always at least 2 arguments, because an NSMethodSignature
		 object includes the hidden arguments self and _cmd, which are the
		 first two arguments passed to every method implementation.

		 NSMethodSignature Class Reference ...
		 Indices 0 and 1 indicate the hidden arguments self and _cmd,
		 respectively; you should set these values directly with the
		 setTarget: and setSelector: methods. Use indices 2 and greater
		 for the arguments normally passed in a message.
		 */

		NSUInteger argumentCount = [theSignature numberOfArguments] - 2;

		if (parameterCount == argumentCount)
		{
			[theInvocation setTarget:self];		 // There's our index 0.
			[theInvocation setSelector:theSelector]; // There's our index 1.

			// Now for arguments 2 and up...
			NSUInteger i, count = parameterCount;

			for (i = 0; i < count; i++) {

				// We're agnostic about object types, so assume nothing.
				id currentValue = [parameterValues objectAtIndex:i];

				// Well, not entirely agnostic. We do have one problem
				// case that is likely to occur somewhat frequently.
				//
				// Objective-C data types, like int, float, etc., are
				// not objects.  We can't pass them in an array. However,
				// there are many methods that take these types of
				// parameters.  Since we have a goal of supporting
				// arbitrary methods--without modifying them--we need
				// some way to transport these.  A quick and simple way
				// so to wrap them in an NSValue object, then add them
				// to our array.
				//
				// Good so now we have our NSValue.  Now what? Well,
				// now we need to unwrap the basic value nestled inside.
				// Once tranformed, we can pass it as a parameter.
				// Here's how we do that:
				//
				// Test to see if we have a foundation class
				// wrapped in an NSValue.
				if ([currentValue isKindOfClass:[NSValue class]])
				{
					void *bufferForValue;
					[currentValue getValue:&bufferForValue];
					[theInvocation
						setArgument:&bufferForValue
						atIndex:(i + 2)];
					// The +2 represents the (self) and (cmd) offsets
				} else
				{
					[theInvocation
						setArgument:&currentValue
						atIndex:(i + 2)];
					// Again, our +2 represents (self) and (cmd) offsets
				}
			}
			// That's it! (For our NSInvocation).
		}
		// Now we use the invocation to create our operation, which I explain
		// a bit more about below.  I'm including it as reference, since
		// there are good advantages to using a queue.
		theOperation = [[NSInvocationOperation alloc]
					initWithInvocation:theInvocation];
	}
	else
	{	// Okay. We were not passed an array in our context parameter.
		// Well, that's just fine.  If we received something, we'll just
		// pass it on.  This way, our users don't have to go through the
		// hassle of creating an NSArray of just one item.  We could check
		// to see if our selector has just one parameter, and then ensure
		// that context is not nil, but that's left as an exercise to
		// the reader.
		// Note, context is of type (void), so it doesn't need to be
		// wrapped/unwrapped in an NSValue object.  Woo hoo!
		// Invoke a selector with a single parameter.
		theOperation = [[NSInvocationOperation alloc]
					initWithTarget:self
					selector:NSSelectorFromString(aSelector)
					object:context];
	}
	// In this example, I'm submitting my NSInvocationOperation
	// to an NSOperationQueue, which I have already built using
	// a singleton pattern.  You could also use NSThread, but
	// there are some pluses to using NSInvocationQueues for my
	// application (and probably yours too). For NSThread, you
	// use NSInvocation instead of NSInvocationOperation, and
	// might end up with something like:

	// [theInvocation performSelectorInBackground:@selector(invoke) withObject:nil]

	// where the invoke selector is sent to theInvocation, telling it to
	// call the method with the arguements as we defined above, but on
	// a background thread.  The other performSelector* methods work similarly.
	//
	// In this case, though, I'm adding my operation to the queue.
	// Add the operation to the internal operation queue
	// managed by our application delegate.
	[[myAppDelegate sharedOperationQueue] addOperation:theOperation] ;

	// Make sure theOperation gets released later, once it's it finished running.
	[theOperation release];
}

To invoke our, er, invocation, we just send a message like:

[self performSelector:@selector(myMethodWithA:andB:andC:)
        withContext:myArrayOfObjects];

Pretty convenient, and very flexible. When using the built-in convenience methods that Apple provides, the object that you pass to the withObject: parameter is retained automatically. This is not the case, by default, when using NSInvocation. If your code relies on that auto-retain, not to worry. All you need to do is add [theInvocation retainArguments] before you invoke (say at line 21 above).

Let’s take a breath. We covered a lot of ground…but not all of it. When you’re ready, test your endurance with Part II of this article, where we streamline our new code.

If you are building child panes in your Settings.bundle, you’ll end up with several .plist files. When it comes time to localize your project, you find the creation of the corresponding .strings file a bit tedious (I know I do).

Here’s a handy list bash script which will (i) find tags, (ii) extract the contents of the following tag, and then (iii) output that value to a text file in the “string” = “string” format needed for ibtool.

You pass the input and output file names as parameters.

#!/bin/sh
echo "//Manual edits will be overwritten the next time this script runs.// Generated by plist2strings.\n/* A single strings file, whose title is specified in your preferences schema. The strings files provide the localized content to display to the user for each of your preferences. */\n" > plist2stringstmp
sed -n '
# look for a "#" at the end of the line
/<key>Title<\/key>$/ {
# Found one - now read in the next line
	N
# delete the "#" and the new line character,
	s/.*<\(string\)>\(.*\)<\/\1>/"\2" = "\2"/gp
}' $1 > plist2stringstmp2
cat plist2stringstmp plist2stringstmp2 > $2
rm plist2stringstmp plist2stringstmp2

Copy-N-Paste into a text file. I saved mine as plist2strings. Be sure to give it execute permissions. For example, in Terminal execute:

 macbook:~ foo$ chmod 755 plist2strings

To execute the script (if saved to your user folder) from root of your Settings.bundle directory, just use the syntax:

 macbook:~ foo$ ~/plist2strings mysettings.plist en.lprog/mysettings.strings

If mysettings.strings is not already present in that folder, it will create it. If it is already there, it will automatically overwrite it without warning.

Hope someone finds this useful. And feel free to use (and abuse) as you see fit (caveat emptor ). If you make any useful changes, consider posting them back up here for others to enjoy too.

Happy Localizing!