This question shows research effort; it is useful and clear
8
Save this question.
Show activity on this post.
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.
asked May 17, 2010 at 22:00
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];
}
answered May 18, 2010 at 0:20
7 Comments
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?
Unfortunately, it's mostly all or nothing. Through the use of #pragma GCC diagnostic ... (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 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: 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.
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.
|
if([[UIApplication sharedApplication]
respondsToSelector:@selector(setStatusBarHidden:withAnimation:)]) {
[[UIApplication sharedApplication] setStatusBarHidden:YES withAnimation:UIStatusBarAnimationSlide];
} else {
[(id)[UIApplication sharedApplication] setStatusBarHidden:YES animated:NO];
}
Comments
Explore related questions
See similar questions with these tags.