insidiousbugs

[insidiousbugs]

topLayoutGuide is great, until it's not.

UIViewController's topLayoutGuide is a great method.

From the documentation: "It indicates the highest vertical extent for content that you don't want to appear behind a translucent or transparent UIKit bar (such as a status or navigation bar)."

Sounds great. No longer do you have to get the height of the navigation bar, and then the status bar, and then add them together. Well, unless you're using a UITableViewController that is.

If you simply reference, and by reference I mean write the following: self.topLayoutGuide;, anywhere in a UITableViewController subclass, it prevents scrolling. You'll still get the rubber banding effect, but your content will no longer be scrollable.

Sounds pretty crazy, but the old way of adding the heights together still works. On the plus side, topLayoutGuide works fine with interface builder and autolayout. So there's that.

[insidiousbugs]

- (BOOL)hasText is a lie.

The UIKeyInput protocol defines a -(BOOL)hasText method. Typically you would call this on a UITextView or UITextField to determine if the receiver has text in it.

Consider this example:

UITextField *textField = [[UITextField alloc] init]; [self.view addSubview:textField]; NSLog(@"%i", [textField hasText]); [textField setText:@"Letter"]; NSLog(@"%i", [textField hasText]); [textField becomeFirstResponder]; dispatch_async(dispatch_get_main_queue(), ^{ NSLog(@"%i", [textField hasText]); });

You would think the output from those NSLogs would be:

0 1 1

Wrong. The actually print out is:

0 6 1

Apparently, when the object conforming to UIKeyInput is not the first responder, hasText returns the length of the string.

Normally this wouldn't cause anyone any problems. For instance in this condition:

if ([textField hasText]) { NSLog(@"Great!"); }

Everything here will be fine. The length of the string in this case is essentially equivalent to if hasText were to always return a BOOL instead of the length.

However, if someone were to write:

if ([textField hasText] == YES) { NSLog(@"Not Great :("); }

That would not be fine if the text field were not the first responder. 6 == YES would be false, and nothing would print to the console.

Here comes the insidious bug.

-(BOOL)alertViewShouldEnableFirstOtherButton:(UIAlertView *)alertView

If you return [textField hasText] from this UIAlertViewDelegate method, you will be making a mistake. Without knowledge of the internals of this UIKit method, it appears that it is making an == YES check on the value you provide. You can read about why that would be a bad idea over at the Big Nerd Ranch.

This can cause the button to be disabled if the text field you are checking is not the first responder, and it has an even number of characters.

Open Radar Bug Report

[insidiousbugs]

NSAssert References self

NSAssert and its related macros reference self. If you NSAssert in a block that self retains, you will create a retain cycle. This only occurs when running in any build configuration that doesn't block assertions.

#define NSAssert(condition, desc, ...) \ do { \ __PRAGMA_PUSH_NO_EXTRA_ARG_WARNINGS \ if (!(condition)) { \ [[NSAssertionHandler currentHandler] handleFailureInMethod:_cmd \ object:self file:[NSString stringWithUTF8String:__FILE__] \ lineNumber:__LINE__ description:(desc), ##__VA_ARGS__]; \ } \ __PRAGMA_POP_NO_EXTRA_ARG_WARNINGS \ } while(0)

You can use NSCAssert to get around this, but that technically isn't supposed to be used in Objective-C methods.

I discovered this bug while reading Drew Crawford's post on NSNotificationCenter.