if ([self respondsToSelector:@selector(dismissViewControllerAnimated:completion:)])
{[[self presentingViewController] dismissViewControllerAnimated:YES completion:nil];} //post-iOS6.0
else {[self dismissModalViewControllerAnimated:YES];} //pre-iOS6.0
I'm doing the responds to selector (above) code to handle deprecated methods. That way my app is compatible with older versions of iOS, but I'm getting warnings in my code stating: "'dismissModalViewControllerAnimated:' is deprecated: first deprecated in iOS 6.0" I personally don't like any warning in my code, but more importantly, I read somewhere that apple will complain about warnings in your code.
1) Will Apple complain about warnings in your code?
2) Am I handling deprecated methods correctly?
3) Is there way to turn deprecated method method warnings off?
Place the @SuppressWarnings annotation at the declaration of the class, method, field, or local variable that uses a deprecated API. The @SuppressWarnings options are: @SuppressWarnings("deprecation") — Suppresses only the ordinary deprecation warnings.
Deprecation warnings are a common thing in our industry. They are warnings that notify us that a specific feature (e.g. a method) will be removed soon (usually in the next minor or major version) and should be replaced with something else.
Deprecated methods or classes that are outdated one which will eventually be removed.
Instead of a single statement, you can also mark a function, a class or a file ( @file:Suppress("DEPRECATION") in its beginning) with the annotation to suppress all the deprecation warnings issued there. In IntelliJ IDEA this can also be done through Alt + Enter menu with caret placed on code with deprecation warning.
Apple is unaware of any compile-time warnings you receive with your code.
Yes, you are handling this practice correctly. Clearly, in this case, you only need to go through this effort if you're supporting iOS prior to 5.0. But, in general, the technique for testing whether a method can be invoked and then calling the appropriate rendition is absolutely correct.
If you want to turn off the warning, you would simply temporarily suppress the warning and then turn it back on afterwards using the appropriate #pragma
syntax:
if ([self respondsToSelector:@selector(dismissViewControllerAnimated:completion:)])
{
//post-iOS6.0
[self dismissViewControllerAnimated:YES completion:nil];
}
else
{
// pre-iOS6.0
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wdeprecated-declarations"
[self dismissModalViewControllerAnimated:YES];
#pragma clang diagnostic pop
}
By the way, if you want to know what the -W
code is for your particular warning, go to your Log Navigator, select the recent build that included the warning, and expand the log, and you'll see it there:
Also note that while you could suppress the warning like I've illustrated above, in practice, you rarely need to do so. Using your example, if your project's iOS deployment target was 4.3, you wouldn't get the warning. And if your deployment target was 6.0 or higher, you'd get that warning, but then again, you probably wouldn't need this conditional code to call dismissModalViewControllerAnimated
because effective iOS 5.0, you can always use dismissViewControllerAnimated
.
The only time that you'd need to suppress this warning in your code is if you have source code, to be included in projects in the future, for which you don't know what the deployment target will be. Using your example, if you don't know whether the above code will be included in a project with a 4.3 deployment target or a 5.0+ deployment target. In that case, this syntax is quite useful. But, then again, I you could also use conditional checks on __IPHONE_OS_VERSION_MIN_REQUIRED
, e.g.:
#if __IPHONE_OS_VERSION_MIN_REQUIRED < __IPHONE_5_0
if ([self respondsToSelector:@selector(dismissViewControllerAnimated:completion:)])
{
//post-iOS5.0
[self dismissViewControllerAnimated:YES completion:nil];
}
else
{
// pre-iOS5.0
[self dismissModalViewControllerAnimated:YES];
}
#else
[self dismissViewControllerAnimated:YES completion:nil];
#endif
If you are really interested in backwards compatibility, there is a great tutorial by Ray Wenderlich here
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With