2010-12-14 32 views
7

Je voudrais savoir comment vous vérifiez que votre code n'appelle pas les méthodes non disponibles lorsque la cible de déploiement est inférieure au SDK de base?Comment vérifier si des méthodes non disponibles sont utilisées si la cible de déploiement <base sdk?

Il est possible d'exécuter l'application sur un périphérique avec le SDK égal à la cible de déploiement, mais je recherche beaucoup plus "automatique". Une idée ?

Cordialement, Quentin

+1

Je pense qu'il veut des avertissements de compilation pour les méthodes manquantes lorsque sur un iOS inférieur à la base SDK. XCode ne vous donnera que des avertissements au moment de la compilation pour le sdk de base installé, donc je ne pense pas que ce soit possible. Si vous ne devez tester qu'un seul périphérique, vous pouvez écrire un tas de scénarios de test pour ce périphérique et les exécuter. – vakio

+0

Exactement! Donc, ce n'est pas possible :(. – Quentin

+0

duplication possible de [Y at-il un moyen pour XCode d'avertir de nouveaux appels d'API?] (Http://stackoverflow.com/questions/4676000/-there-a-way-for- xcode-to-warn-about-new-api-calls) – JosephH

Répondre

0
  1. meilleure façon de faire ce que je trouve: compiler le code avec le vieux SDK :) link which can help

  2. Je pense que cette question est releated avec next

  3. Je belive qu'un jour d'Apple permet de compiler projet pour le vieux SDK par une simple définition #define __IPHONE_OS_VERSION_MAX_ALLOWED __IPHONE_3_0

  4. màj: J'ai trouvé la solution here

4,3 5,0 et 5.1 SDK échouerait compiler après avoir essayé de redéfinir cette macro

2

utilisation NSClassFromString();

Class cls = NSClassFromString(@"YourClass"); 
if (cls == nil) 

est ce que vous cherchez?

+0

if ([classe NSOrderedSet])!= 0) fonctionne mieux sur iOS 4.2+ compilé avec LLVM 1.6+. (voir http://www.marco.org/2010/11/22/supporting-older-versions-of-ios-while-using-new-apis) –

0

Vous cherchez quelque chose comme - (BOOL) respondsToSelector: (SEL) unSelecteur

0

Si vous avez une instance d'une classe, vous pouvez utiliser ce qui suit pour voir si elle comprend la méthode que vous voulez appeler :

if ([mipmapBrowserView respondsToSelector:@selector(setBackgroundColor:)]) { 
    // set the background layer since IKImageView supports it 
} 

ici, mipmapBrowserView est une instance de IKImageView, qui a été introduit sous Mac OS X 10.5. La méthode setBackgroundColor: de IKImageView a été seulement ajoutée dans 10.6, cependant, j'ai besoin de vérifier avant de l'appeler. Cela me permet de construire sur le SDK 10.6, et de tirer parti des nouvelles fonctionnalités, tout en prenant en charge OS X 10.5. Bien que cet exemple implique OS X plutôt que iOS, la même méthode (jeu de mots?) Fonctionne également dans iOS.

Notez que les choses sont légèrement différentes lorsque vous êtes sous-classement d'une classe, et vous voulez savoir si la superclasse répond à un certain sélecteur:

« Vous ne pouvez pas vérifier si un objet hérite d'une méthode de sa superclasse en envoyant respondsToSelector: à l'objet en utilisant le super mot clé.Cette méthode testera toujours l'objet dans son ensemble, et pas seulement l'implémentation de la superclasse.Par conséquent, envoyer respondsToSelector: à super équivaut à l'envoyer à self. la méthode de classe NSObject instancesRespondToSelector: directement sur la superclasse de l'objet .... "

3

La meilleure façon de le faire est d'utiliser le préprocesseur définir __IPHONE_OS_VERSION_MAX_ALLOWED.

Vous faites cela en ajoutant l'option

__IPHONE_OS_VERSION_MAX_ALLOWED=__IPHONE_4_2 

ou quelque chose de similaire à votre « macros préprocesseur » dans les paramètres de compilation de votre cible. Vous pouvez rechercher les versions disponibles dans <Availability.h>. Malheureusement, si vous ajoutez ceci, cela entraînera des erreurs de correspondance avec votre en-tête précompilé. Donc, pour résoudre ce problème, vous devez également désactiver l'option "Précompilier l'en-tête de préfixe" dans vos paramètres de construction. Une fois que vous faites cela, vous aurez un tas d'erreurs pour les classes qui n'existent pas sur votre SDK ciblé (par exemple NSOrderedSet n'existe pas dans iOS 4.2). Si vous essayez de revenir pré-iOS 4, vous aurez probablement autant d'erreurs que le compilateur bails - Je ne connais pas de solution de contournement pour cela. Dans tous les cas, ignorez les erreurs sur les classes manquantes dans les en-têtes UIKit, et allez au bas de la liste des erreurs; là vous devriez trouver une erreur pour chaque fois que vous utilisez une méthode ou une classe qui n'est pas incluse dans le SDK pointé par __IPHONE_OS_VERSION_MAX_ALLOWED. Assurez-vous que chacune de ces méthodes est incluse dans un

if([targetObject respondsToSelector:@selector(thePossiblyMissingSelector:)] 

et vous devriez être en sécurité. Les classes qui peuvent être manquantes doivent être testées également

if ([NSOrderedSet class] != nil) 

Ces paramètres ne sont cependant pas quelque chose que vous voulez oublier accidentellement. Pour en faire une option automatique de test, procédez comme suit:

  1. Créez une nouvelle configuration de construction appelée quelque chose comme "Ancien test SDK".
  2. Définissez __IPHONE_OS_VERSION_MAX_ALLOWED et l'option de tête précompilée uniquement pour cette configuration (appuyez sur la flèche de divulgation à côté de chaque ligne dans Paramètres de construction pour accéder aux paramètres de configuration). Dupliquez votre schéma actuel et définissez son nom sur quelque chose comme "Ancien test SDK".
  3. Définissez la configuration de construction de l'élément Exécuter dans ce nouveau schéma sur la configuration de génération que vous avez créée à l'étape 1.
  4. Sélectionnez le nouveau schéma et la nouvelle génération.

Remarques:

  • Je ne fais aucune garantie que cela va attraper tout/tous vos problèmes.
  • Tout ce qui ne fait pas partie d'UIKit ne sera pas détecté par cette vérification.
  • Ce n'est pas un substitut pour tester votre code sur les versions d'iOS que vous planifier pour prendre en charge.