Traitement des méthodes obsolètes dans l'iPhone

Question

Comment gérez-vous les méthodes obsolètes dans l'iPhone qui nécessitent l'utilisation d'une méthode plus récente, non disponible dans les anciennes versions?

Considérons le cas de setStatusBarHidden:animated:, qui était obsolète dans iOS 3.2. La documentation vous indique comment utiliser setStatusBarHidden:withAnimation:, disponible uniquement dans iOS 3.2 ou version ultérieure. Si je comprends bien, cela signifie que pour cibler tous les appareils (iOS 3.0 ou ultérieur), je dois d'abord demander si setStatusBarHidden:withAnimation: est disponible. Si c'est le cas, utilisez-le. Sinon, utilisez la méthode obsolète. Mais je recevrais quand même un avertissement de dépréciation.

Est-ce correct (s'il vous plaît dites que ce n'est pas!)? Si c'est le cas, est-il possible de supprimer cet avertissement de désapprobation ou d'indiquer au compilateur que j'ai déjà traité le problème?

Answer 1

Je trouve une question similar qui suppose que oui , c'est la bonne façon de traiter avec des méthodes dépréciées, et no, il n'y a aucun moyen de supprimer les avertissements de dépréciation au cas par cas, mais il y a des hacks pour tromper le compilateur.

Pour traiter le cas d'exemple, j'ai décidé de créer une classe d'util en utilisant un de ces 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 

Si je ne me trompe pas est utilise respondsToSelector coûteux. Cela pourrait être optimisé pour les performances à retenir si le nouveau sélecteur est présent après la première requête, évitant ainsi le besoin de réflexion dans les appels suivants. Venant d'un arrière-plan Java, je trouve que cette façon de traiter la dépréciation est effroyable et je n'arrive toujours pas à croire que les concepteurs iOS s'attendent à ce que nous ayons à faire face à ce problème. Plus de réflexions sur le sujet seront très appréciées.

Answer 2

Il y a probablement une meilleure réponse, mais ce que je faisais était une fois:

1 Vérifiez si le deprecatedMethod est disponible. (En utilisant la méthode respondsToSelector:)

2 Si oui, alors appeler cette méthode en utilisant la fonction objective-c exécution:

id objc_msgSend(id theReceiver, SEL theSelector, ...) 

lorsque vous utilisez cette fonction, le compilateur ne vous donnera aucun avertissement :)

3 autre utilisation rationnelle de la nouvelle méthode

Answer 3

méthode Invoquer cette façon:

id objc_msgSend(id theReceiver, SEL theSelector, ...)

sera meilleur choix si vous voulez omettre avertissant que UIApplication peut ne pas répondre à la méthode setStatusBarHidden:withAnimation: (dans iOS 3.0 ou version ultérieure).