Archive for September, 2009

Bike Brake

Wednesday, September 16th, 2009
Package.jpg

I rode my recumbent bike over to REI to pick up a new pannier. Because the geometry is a bit different, I wheeled the bike into the store so I could effectively “try on” a number of panniers to find the best fit.

While there, I ran into a nice gentleman who asked about the bike and saw me do the typical balance dance trying to lean my bike up against something. You know the one; lean it up… looks stable… starts rolling… handlebars turn… *catch*… repeat.

He mentioned that he had invented a solution. Specifically, he created the Bike Brake. He offered to send me one for free and I received it yesterday.

Brilliant invention. Dead simple, but just works.

It is effectively a rubber band with a couple of tabs to make it easier to grab. While you could use a regular rubber band, it wouldn’t work nearly as well.

Notably, the Bike Brake is stretchy enough to sit tightly on your handle when not in use, but is still able to easily stretch around the brake handle. The tabs make it very easy to use and it is wide enough to provide the strength necessary to keep the front wheel (the problem wheel) locked.

At $2.99 + free shipping, it is cheap and there are a bunch of colors. I’m going to order some more for the other bikes in our house.

It has completely eliminated “the bike parking dance”.

Class Extensions Explained

Friday, September 11th, 2009

One of the features added to Objective-C 2.0 is Class Extensions.

If you have feature requests or bugs, http://bugreport.apple.com/ is your friend!

There has been a bit of confusion about their functionality and purpose.

First, a bit of background. One of the great strengths of Objective-C is the very sharp division between interface and implementation.

Not only can you declare a public interface to a class — the set of methods that clients of the class can use — but you can also declare varying degrees of private interface ranging from “stuff for my framework” through to “stuff only to be used in the implementation of this subset of methods of the class”.

Class extensions were designed to solve two problems. The first was to enable to compiler to better validate the private interfaces a class might have and the second was to solve a subtle, but gnarly, problem with properties (another feature added to Objective-C 2.0).

Read the rest of this entry »

+initialize Can Be Executed Multiple Times (+load not so much)

Sunday, September 6th, 2009

Some confusion on StackOverflow led to a massive string of comments. This is a question that comes up often, so here is some google fodder.

In Objective-C, a class can implement +initialize. This method will be invoked the first time the class is touched, prior to any other methods (other than +load).

The documentation says:

The runtime sends initialize to each class in a program exactly one time just before the class, or any class that inherits from it, is sent its first message from within the program.

Which is exactly true. But your +initialize methods can still be executed more than once!

Specifically, if a subclass does not implement +initialize but its superclass does, then that superclass’s +initialize will be invoked once per non-implementing subclass and once for itself.

An example (Foundation Tool, Garbage Collected):

@interface Abstract: NSObject
@end
@implementation Abstract
+ (void) initialize
{
    NSLog(@"Initializing %@", self);
}

+ (void) load
{
    NSLog(@"Loading");
}
@end

@interface Sub : Abstract
@end
@implementation Sub
@end

int main (int argc, const char * argv[]) {
    [Sub class];
    return 0;
}

This will output:

ArgyBargy[3720:903] Loading
ArgyBargy[3720:903] Initializing Abstract
ArgyBargy[3720:903] Initializing Sub

Which is why most +initialize methods are implemented as:

@implementation MyClass
+ (void) initialize
{
    if (self == [MyClass class]) {
        // ... do +init stuff here ...
    }
}
...
@end

Now, categories can seriously screw things up (as usual). Namely, if you implement +initialize in a category, it will override the classes +initialize. However, a category provided +load will not; both the category’s and the class’s +load methods will be invoked.

If you were to add the following category to the Sub/Abstract/NSObject example above:

@interface Abstract(Cat)
@end
@implementation Abstract(Cat)
+ (void) load
{
    NSLog(@"Category +load");
}
+ (void) initialize
{
    NSLog(@"Category +initialize %@", self);
}
@end

The program will spew:

ArgyBargy[3919:903] Loading
ArgyBargy[3919:903] Category +load
ArgyBargy[3919:903] Category +initialize Abstract
ArgyBargy[3919:903] Category +initialize Sub

Keep in mind, as well, that the runtime sends +initialize “in a thread-safe manner”. That implies that there is a lock involved somewhere within which then also implies that you better not block on a lock in your +initialize because whoever is supposed to unlock the lock might end up blocking on +initializes lock.

Or, to put it more bluntly, do not do any heavy lifting in +initialize. Keep it super simple & fast.

For me, +initialize is to be used only as a method of last resort. Well, 2nd to last. Last resort is a constructor attributed function (or +load). Read the rest of this entry »