8

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.

Community
  • 1
  • 1
MrHen
  • 2,420
  • 2
  • 25
  • 39

2 Answers2

5

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];
}
mbauman
  • 30,958
  • 4
  • 88
  • 123
  • 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 May 18 '10 at 16:58
  • 1
    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. – mbauman May 18 '10 at 17:48
  • 1
    @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 May 24 '10 at 16:06
  • 1
    @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. – mbauman May 24 '10 at 17:39
  • 2
    This works for me, but I do have to make one change. My code reads: id app = (id)[UIApplication sharedApplication]; Otherwise that line gives me a warning. – William Jockusch Jun 24 '10 at 19:47
  • Ah, of course. I generally do it all in one line (`(id)[UIApplication sharedApplication] setStatusBarHidden:YES animated:NO];`), but I broke it into two for the post for readability. Thanks for the note, @William. – mbauman Jun 24 '10 at 20:47
  • @MattB.: "the compiler checks to ensure that at least some class is able to respond to such a selector." The compiler simply cares that it is declared *somewhere* in the current scope. It doesn't care where. Since you are getting a deprecated warning, it is declared somewhere as deprecated. So using `id` will always work. – user102008 Apr 24 '12 at 20:56
0
if([[UIApplication sharedApplication]
  respondsToSelector:@selector(setStatusBarHidden:withAnimation:)]) {

  [[UIApplication sharedApplication] setStatusBarHidden:YES withAnimation:UIStatusBarAnimationSlide];
 } else {
  [(id)[UIApplication sharedApplication] setStatusBarHidden:YES animated:NO];
 }
user102008
  • 30,736
  • 10
  • 83
  • 104