views:

694

answers:

1

Similar to Ben Gottlieb's question, I have a handful of deprecated calls that are bugging me. Is there a way to suppress warnings by line? For instance:

 if([[UIApplication sharedApplication]
  respondsToSelector:@selector(setStatusBarHidden:withAnimation:)]) {

  [[UIApplication sharedApplication] setStatusBarHidden:YES withAnimation:UIStatusBarAnimationSlide];
 } else {
  [[UIApplication sharedApplication] setStatusBarHidden:YES animated:NO]; //causes deprecation warning
 }

All I care about is that line. I don't want to turn off all deprecation warnings. I would also rather not do something like suppress specific warnings by file.

There have been a few other circumstances where I wanted to flag a specific line as okay even though the compiler generates a warning. I essentially want to let my team know that the problem has been handled and stop getting bugged about the same line over and over.

+2  A: 

Vincent Gable has posted an interesting solution. In short:

@protocol UIApplicationDeprecatedMethods
- (void)setStatusBarHidden:(BOOL)hidden animated:(BOOL)animated;
@end

if([[UIApplication sharedApplication] respondsToSelector:@selector(setStatusBarHidden:withAnimation:)]) {
    [[UIApplication sharedApplication] setStatusBarHidden:YES withAnimation:UIStatusBarAnimationSlide]; 
} else { 
    id<UIApplicationDeprecatedMethods> app = [UIApplication sharedApplication];
    [app setStatusBarHidden:YES animated:NO];
}
Matt B.
Cool. I guess that works for dodging the deprecation warnings. The more abstract question is still open, however. Is there a way to suppress a specific warning in XCode?
MrHen
Unfortunately, it's mostly all or nothing. Through the use of `#pragma GCC diagnostic ...` (http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html), you can disable a specific warning on a per-file basis in a more obvious way than the per-file build settings. It does require GCC 4.2+, and must be placed at the very top of a translation unit.
Matt B.
@matt-b FYI, I think I found a better way to deal with the deprecation warnings. If I cast UIApplication to (id) the error goes away. Can you think of a reason this is improper?
MrHen
@MrHen: Yes, that does sometimes work. When you send `id` a selector, the compiler checks to ensure that at least _some_ class is able to respond to such a selector. That may not always be the case with a deprecated selector. If not, a no method found warning is raised. Thus, adding a protocol is the more robust solution; it will always circumvent the warning.
Matt B.
This works for me, but I do have to make one change. My code reads: id<UIApplicationDeprecatedMethods> app = (id)[UIApplication sharedApplication];Otherwise that line gives me a warning.
William Jockusch
Ah, of course. I generally do it all in one line (`(id<UIApplicationDeprecatedMethods>)[UIApplication sharedApplication] setStatusBarHidden:YES animated:NO];`), but I broke it into two for the post for readability. Thanks for the note, @William.
Matt B.