处理iPhone中不推荐使用的方法 [英] Dealing with deprecated methods in iPhone

问题描述

如何处理iPhone中不推荐使用的方法，而该方法要求您使用较新的方法，而在较旧的版本中不可用？

How do you deal with deprecated methods in iPhone that require you to use a newer method, not available in older versions?

考虑 setStatusBarHidden：animated：，在iOS 3.2中已弃用。文档指出您可以使用 setStatusBarHidden：withAnimation：，该功能仅在iOS 3.2或更高版本中可用。

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.

如果我正确理解，这意味着要定位所有设备（iOS 3.0或更高版本），我首先要问 setStatusBarHidden：withAnimation：是否可用。如果是这样，请使用它。如果不是，请使用不建议使用的方法。但是我仍然会收到过时的警告。

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?

推荐答案

我发现了一个类似问题，该问题假定是，这是处理过时方法的正确方法，否，没有办法根据具体情况来抑制过时警告，但是有一些技巧会误导编译器。

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.

为了处理示例，我决定使用以下一种黑客方式创建util类：

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

如果我没弄错使用 respondsToSelector 是昂贵的。可以通过优化性能来记住在第一次查询后是否存在新选择器，从而避免在后续调用中进行反射。

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.

来自Java背景，我发现这种处理折旧的方法令人震惊，但我仍然无法相信这是iOS设计师希望我们处理此问题的方式。在这个问题上有更多的想法将不胜感激。

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.

这篇关于处理iPhone中不推荐使用的方法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！