How do you deal with deprecated methods in iPhone that require you to use a newer method, not available in older versions?
Consider the case of setStatusBarHidden:animated:
, which was deprecated in iOS 3.2. The documentation points you to use setStatusBarHidden:withAnimation:
, which is only available in iOS 3.2 or later.
If I understand correctly, this means that to target all devices (iOS 3.0 or later), I have to ask first if setStatusBarHidden:withAnimation:
is available. If it is, use it. If not, use the deprecated method. But I would still get a warning of deprecation.
Is this correct (please say it isn't!)? If it is, is there any way to suppress this deprecation warning, or to indicate the compiler that I have already handled the problem?
Navigate to Issue Navigator. In the Issue navigator, type "deprecated" in the below filter. Now you will be able to see all (and only) deprecated Buildtime warnings.
In information technology (IT), deprecation means that although something is available or allowed, it is not recommended or that -- in the case where something must be used -- to say it is deprecated means that its failings are recognized.
You could mark the specific method if it's used from an SDK as deprecated and obsoleted as follows: @available(iOS, deprecated: 12, obsoleted: 13, message: "We no longer show an app introduction on iOS 14 and up") func launchAppIntroduction() { // .. } Marking a method as deprecated in Swift.
Deprecation means that we've ended official support for the APIs, but they will continue to remain available to developers. This page highlights some of the deprecations in this release of Android.
I found a similar question that assumes that yes, this is the correct way of dealing with deprecated methods, and no, there is no way to suppress deprecation warnings on a per-case basis, but there are hacks to mislead the compiler.
To deal with the example case, I decided to create an util class using one of these hacks:
@protocol UIApplicationDeprecated
- (void) setStatusBarHidden:(BOOL)hidden animated:(BOOL)animated;
@end
@implementation UIUtils
+ (void) setStatusBarHidden:(BOOL)hidden animated:(BOOL)animated {
if([[UIApplication sharedApplication] respondsToSelector:@selector(setStatusBarHidden:withAnimation:)]) {
[[UIApplication sharedApplication] setStatusBarHidden:hidden withAnimation:animated ? UIStatusBarAnimationSlide : UIStatusBarAnimationNone];
} else {
id<UIApplicationDeprecated> app = (id)[UIApplication sharedApplication];
[app setStatusBarHidden:hidden animated:animated];
}
}
@end
If I'm not mistaken using respondsToSelector
is costly. This could be optimized for performance to remember if the new selector is present after the first query, thus avoiding the need for reflection in subsequent calls.
Coming from a Java background, I find this way of dealing with deprecation appalling and I still can't believe that this is how iOS designers expect us to deal with this problem. More thoughts on the subject will be much appreciated.
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