Multi-Row Delete in 3.0

The networkpx Project Blog has an interesting post on doing multi-row delete under SDK 3.0. It's a good post, even if they do credit the excellent Cocoa with Love blog for "introducing" a technique that I demonstrated three months earlier.

Anyway, the ability to do multi-row delete is now built-into UITableView starting with SDK 3.0, meaning you can now implement multi-row delete it with just few lines of code. Yay.

Or, perhaps not.

Unfortunately, using this functionality requires you to return an undocumented UITableViewCellEditingStyle value from tableView:editingStyleForRowAtIndexPath: in order to turn this feature on. To fully utilize the functionality, you have to use and override other undocumented, private methods.

Technically, doing that in an application submitted to the App Store violates your SDK agreement and is grounds for having your application rejected.

Will your apps be rejected if you do it? Who knows? Maybe yes, maybe no. It's even possible that people using the older, manual technique will get their apps rejected for using private methods even though that technique doesn't, similar to the Coverflow debacle from last year.

Now, I'm not going to advise you whether to use this functionality in your apps. It's a risk, and you have to decide how risk tolerant you are. I am going to advise that if you have any desire to use this functionality at all, go now and open a bug report with Apple requesting that they make the multi-row delete functionality available to developers.

UIAlertView & Landscape Mode

I've been wrestling with something today. I think this is new incorrect behavior. I could be wrong about it being new, but it definitely seems incorrect.

When your application is in landscape mode, and you show an UIAlertView, that alert view gets shown in portrait mode, meaning it's sideways to the user. Obviously, that makes it awkward and a little hard to read.

I tried many things to get it to work right, without much success. If I changed the view's transformation before the view was shown to the user, it got overwritten and put in the incorrect orientation anyway. My attempts to subclass UIAlertView were unsuccessful in fixing the problem. The best I could do was to change the view's orientation right after it's displayed to the user, animating the change to make it less jarring.

In order to do that, you have to implement the delegate method didPresentAlertView: on your view's delegate. If you're not using a delegate, simply pass self and implement this method in your controller class where you create and show the alert.

- (void)didPresentAlertView:(UIAlertView *)alertView
{
    [UIView beginAnimations:@"" context:nil];
    [UIView setAnimationDuration:0.1];
    alertView.transform = CGAffineTransformRotate(alertView.transform, degreesToRadian(90));
    [UIView commitAnimations];
}

I have submitted this as a bug to Apple, and I have to assume I'm not the only one who has, but in the meantime, this is the best I've been able to come up with. If anyone has a better solution, I'd love to hear it. I'm not looking forward to letting my client see their app like this.

Radar URLs & Bug Reporting

Okay, most iPhone developers have likely discovered the Apple Bug Reporter and have likely used it on more than one occasion. If you're one of the few who haven't, though, there's the link right back there. Bookmark it, and use it. Use it for bugs. Use it for enhancements. It is the one and only official mechanism for letting Apple know about both bugs and things we don't like. Posting to forums or mailing lists - even those run by Apple - does not get your complaint in front of anybody with the ability to fix or change it.

If you do use the bug reporter, though, make sure you're thorough and follow their format. Give them detailed replication instructions. And, be formal and polite. Remember: a real person will be reading what you write, and that person may very well be the programmer who wrote the code that you don't like or think has a bug.

Here's a little thing that confuses a lot of newcomers to the Apple development world - those darn Radar URLs, the ones that look like this : rdar://problem/12345. They never work, do they? The reason is that those URLs aren't meant for you, they're meant for the internal Apple engineers with special software installed to let them access the Radar bug tracking system. There's not even a way (that I know of) to map those URLs to RadarWeb, the web-based bug-reporting tool that we all have to use, and even if you could, RadarWeb is not going to let you get to reports you didn't create or are otherwise linked to

So, next time you see one of those rdar:// urls, just remember, it's not for you and don't bother trying to click it, okay?


Wolf Rentzsh has a little more information on Radar URLs, including the format and why they're used outside of Apple.