Componentix blog

I’ve recently stumbled upon Mike Abdullah’s blog post which has raised an interesting issue. When ARC is used, weak properties can be set to nil by the runtime. However if you register for KVO notifications using addObserver method, you won’t get notified of it. This is interesting, as it basically breaks KVO compliance. It is also worth noting that other updates of such properties still result in notifications.

Mike proposed that debugging code can be injected to check for the weak properties used with addObserver. I’ve decided to implement such code:

#import <objc/runtime.h>

void MethodSwizzle(Class c, SEL origSEL, SEL overrideSEL)
{
    Method origMethod = class_getInstanceMethod(c, origSEL);
    Method overrideMethod = class_getInstanceMethod(c, overrideSEL);
    if (class_addMethod(c, origSEL, method_getImplementation(overrideMethod), method_getTypeEncoding(overrideMethod))) {
        class_replaceMethod(c, overrideSEL, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
    } else {
        method_exchangeImplementations(origMethod, overrideMethod);
    }
}

@implementation NSObject (KVOWeakPropertyDebug)

+ (void)load
{
    MethodSwizzle(self, @selector(addObserver:forKeyPath:options:context:), @selector(_addObserver:forKeyPath:options:context:));
}

- (BOOL)_isWeak:(NSString *)keyPath
{
    // TODO: Support complex keyPath variants
    objc_property_t property = class_getProperty(self.class, keyPath.UTF8String);
    if (property) {
        return property_getAttributes(property)[3] == 'W';
    }

    return NO;
}

- (void)_addObserver:(NSObject *)observer forKeyPath:(NSString *)keyPath options:(NSKeyValueObservingOptions)options context:(void *)context
{
    if ([self _isWeak:keyPath]) {
        NSLog(@"WARNING: observing '%@' property, which is weak and so isn't fully KVO-compliant", keyPath);
    }

    [self _addObserver:observer forKeyPath:keyPath options:options context:context];
}

@end

Basically it is a category on NSObject that replaces addObserver method with own implementation using method swizzling. It checks whether observed key corresponds to weak property and logs a warning in such case, then just calls original implementation.

For convenience grab complete code as Gist.

Shameless plug

Check out our new service for iOS developers – hosted continuous integration.

When using UITableView in iOS apps quite often you’d like to customize its design. In particular it is typical to change background color of cells and color of separators. It is usually trivial enough with plain style table views, however may get tricky when you have grouped style table view.

The problem is that if you change backgroundColor property of a cell in a grouped table view you don’t get expected result. So the solution is to change backgroundView of a cell instead. Quite common technique is to use images and so UIImageView for the purpose. However if you want to keep standard look of cells but just change background color and border color it isn’t convenient.

So I’ve createad a reusable background view for this purpose. Thanks to UIBeizierPath class its implementation is trivial, basically main code is drawRect: method:

- (void)drawRect:(CGRect)rect
{
    CGRect bounds = self.bounds;
    UIBezierPath *path;
    if (position == CellPositionSingle) {
        path = [UIBezierPath bezierPathWithRoundedRect:bounds cornerRadius:kCornerRadius];
    } else if (position == CellPositionTop) {
        bounds.size.height += 1;
        path = [UIBezierPath bezierPathWithRoundedRect:bounds
                                     byRoundingCorners:UIRectCornerTopLeft | UIRectCornerTopRight
                                           cornerRadii:CGSizeMake(kCornerRadius, kCornerRadius)];
    } else if (position == CellPositionBottom) {
        path = [UIBezierPath bezierPathWithRoundedRect:bounds
                                     byRoundingCorners:UIRectCornerBottomLeft | UIRectCornerBottomRight
                                           cornerRadii:CGSizeMake(kCornerRadius, kCornerRadius)];
    } else {
        bounds.size.height += 1;
        path = [UIBezierPath bezierPathWithRect:bounds];
    }

    [self.fillColor setFill];
    [self.borderColor setStroke];
    [path fill];
    [path stroke];
}

Using the code is simple, it goes like this:

- (void)drawRect:(CGRect)rect
{
    CGRect bounds = CGRectInset(self.bounds,
                                0.5 / [UIScreen mainScreen].scale,
                                0.5 / [UIScreen mainScreen].scale);
    UIBezierPath *path;
    if (position == CellPositionSingle) {
        path = [UIBezierPath bezierPathWithRoundedRect:bounds cornerRadius:kCornerRadius];
    } else if (position == CellPositionTop) {
        bounds.size.height += 1;
        path = [UIBezierPath bezierPathWithRoundedRect:bounds
                                     byRoundingCorners:UIRectCornerTopLeft | UIRectCornerTopRight
                                           cornerRadii:CGSizeMake(kCornerRadius, kCornerRadius)];
    } else if (position == CellPositionBottom) {
        path = [UIBezierPath bezierPathWithRoundedRect:bounds
                                     byRoundingCorners:UIRectCornerBottomLeft | UIRectCornerBottomRight
                                           cornerRadii:CGSizeMake(kCornerRadius, kCornerRadius)];
    } else {
        bounds.size.height += 1;
        path = [UIBezierPath bezierPathWithRect:bounds];
    }

    [self.fillColor setFill];
    [self.borderColor setStroke];
    [path fill];
    [path stroke];
}

As a result you’ll get something like here:

Note that by using [UIColor colorWithPatternImage:] you can use not only solid colors but textures or gradients as cell background.

Full code is available as Gist, feel free to fork it.

In most cases default tooltip delay of OS X (around 1000 ms) isn’t an issue, as in general you rarely would like to see tooltips all the time you move mouse around.

However while developing one application I had requirement to make tooltip appear faster than that, i.e. decrease tooltip display delay. Hopefully there is a way to do it in OS X.

Tooltip display delay is a property configurable through NSUserDefaults mechanism. So to set it to 50 ms, you can do following:

defaults write -g NSInitialToolTipDelay -int 10000

However that would change preference for whole system, which isn’t something that is desired. But it isn’t a problem – you can set it just for single application:

defaults write com.appdomain.AppName NSInitialToolTipDelay -int 10000

com.appdomain.AppName should be the bundle identifier of the application to change preference for. Of course you can also just automate it in your application:

// Alter tooltip delay setting
[[NSUserDefaults standardUserDefaults] setObject: [NSNumber numberWithInt: 50]
                                          forKey: @"NSInitialToolTipDelay"];

That’s all, hopefully you find it useful.