I use the first method described in the article and put a lock around:

   if (sharedManager == nil) {...}

Two threads call +sharedManager at (more or less) the same time. The earlier call to +sharedManager triggers +initialize on its thread, but before +initialize completes the second thread executes +sharedManager.

When +sharedManager is called on the second thread it can return nil if +initialize hasn’t finished yet on the first thread.

Using some sort of locking is necessary for thread safety.

I use a lock in +sharedManager.around

   if (sharedManager == nil) {...}

Thanks.

@implementation Foo

static id sharedInstance;

+(id)sharedInstance
{
    if (sharedInstance)
        return sharedInstance;

    @synchronized(self)
    {
        if (!sharedInstance)
            sharedInstance = [[self alloc] init];
    }
    return sharedInstance;
}

@end

Seems like my biggest issue now is AppKit’s older method naming scheme; e.g., methods like -setFrame:animate: that present themselves as setters based on their naming scheme but don’t fit in with the dot syntax paradigm because they take additional parameters.

Still think it’d be neat to have key-path functions like @count and @sum, which could call -valueForKeyPath: behind the scenes using the respective functions.

I found if you keep

developmentRegion = English; not modify to developmentRegion = en;

That will be more like what Apple sample did.

It is meant to show off the history of the Bowery. On one side, it has quotes from Walt Whitman and pictures of what is used to look like during Whitman’s time.

But on the other side? It has pictures of this gorgeous old theater, one that tried to survive the new development but couldn’t. And what is so strange is, it doesn’t really specify what was put in its place, which leaves you to believe that this gorgeous old theater that probably deserved landmark status was torn down to build the Whole Foods. It doesn’t say so either way, but the fact that they highlight it is strange.

I remember leaving the display feeling unsettled.

It seems like they are trying to at least honor the history, but instead are building strange proof of what they are part of destroying…

George

If it’s an implementation detail but used by several classes, put the @property declarations in a class extension in a separate file that includes your public header, e.g. put them in “MyClass_Private.h” which includes “MyClass.h”.

You can do this for private methods that you need to expose outside your class as well.

Why would you expose private properties or methods outside a class? Because it may have cooperating classes in the same module that need access, but you don’t want to expose those methods outside that module.

For example, you may expose just a view controller in some API, but the controller interacts with a bunch of private subviews in its implementation.

“To sum up:

Use @property to declare the state exposed by your objects. Use dot notation to get and set objects’ state. Use method declarations to declare the behavior exposed by your objects. Use bracket notation to invoke objects’ behavior.”

What about the case of state that you don’t really want exposed, since it’s private? Should we still use @property thereby making such state public, or forgo and handle it manually keeping it private?

It would be nice if dot syntax was restricted to @property accessors. Even better would be if dot syntax was expanded to include key-path functions like @count, @sum, and included [ ] indexed array access. If that happened, I’d be all in for using it as the primary way to access an object’s properties.

-jcr

For example I may work with NSTableView in a way where it matters to me when it sends me notifications about changing selection, when it reload items, etc. — sometimes the documentation does not make these things clear so (despite attempts of avoiding it) I end up with assertions in my code about how Cocoa acts. This behavior may be wrong in some edge case or it may subtlety change in an OS upgrade.

So I very much want tests (and regression tests) for these things.

Are you doing any interface tests which would not be true in a normal execution of the application?

http://www.duckrowing.com/2010/05/21/using-the-singleton-pattern-in-objective-c/