2009-05-12 7 views
1

J'ai myClass instancié par mon appDelegate, j'ai une autre classe, newClass instanciée par myClass. Dans l'instance newClass, je souhaite accéder à une propriété dans l'instance myClass qui l'a créée. Je l'ai fait par:Avertissement du compilateur "introuvable dans le (s) protocole (s)" lors de l'utilisation du délégué [[[UIApplication sharedApplication]] myClass Property]?

[[[UIApplication sharedApplication].delegate myClass] property] 

Cela fonctionne, je peux réellement obtenir la propriété mais je reçois cet avertissement Xcode:

warning: "-myClass" not found in protocols 
warning: no "-myClass" method found 
(messages without a matching signature will be assumed to return "id" and accept "..." as arguments) 

La propriété NewClass a été déclarée correctement dans le .h et. m fichiers, ses propriétés ont été définies et il a été synthétisé.

Il compile et fonctionne et je peux réellement obtenir la valeur de la propriété.

Devrais-je ignorer l'avertissement dans Xcode?

Existe-t-il un meilleur moyen d'accéder à la propriété de l'occurrence myClass?

Répondre

4

Regardez la documentation - [délégué UIApplication] . Notez qu'il a un type de retour:

id <UIApplicationDelegate> 

Par conséquent, tout ce que vous savez sur l'objet retourné est qu'il est conforme à ce protocole. Il n'y a rien de moins qu'un acte de foi à supposer que le délégué répond au message -myClass, et pas un que le compilateur est prêt à faire.

Vous pouvez pirater un peu travailler comme si:

[[(MyAppDelegateClass *)[[UIApplication sharedApplication] delegate] myClass] property] 

Mais ce serait une mauvaise pratique. Au lieu de cela, je vous suggère de faire votre demande déléguer un singleton afin que vous puissiez faire:

[[[MyAppDelegateClass sharedApplicationDelegate] myClass] property] 
+0

Merci beaucoup Mike Abdullah. Je voulais seulement une variable d'instance particulière. J'ai finalement choisi la solution singleton comme vous l'avez suggéré. –

+0

Désolé, pourquoi exactement cette mauvaise pratique?Cela ressemble au genre de chose que je ferais: p – AriX

+1

Pour commencer, la typographie est généralement un mauvais signe. Dans ce cas, il rend votre code plus fragile en supposant que le délégué de l'application sera * toujours * de cette classe particulière. Au fur et à mesure que votre application se développe, cela peut ne pas être vrai, surtout si vous vous lancez dans des choses comme les tests unitaires. –

0

Je pense qu'au moment de la compilation, Xcode ne peut pas faire le saut à partir des propriétés et de l'objectif-C normal. Il ne peut pas trouver la propriété, donc supposer que vous savez ce que vous faites et remplir les espaces. Au moment de l'exécution, les choses vont bien évidemment.

Essayez ceci:

[[[[UIApplication sharedApplication] delegate] myClass] property]; 

BTW si vous n'avez pas de code comme ceci jonché tout au long de vous possédez un code que je fais habituellement un #define dans l'en-tête du délégué de l'application:

#define APPDELEGATE (myAppDelegate *)[[UIApplication sharedApplication] delegate] 

alors dans le code que je peux simplement aller:

[[APPDELEGATE myClass] property]; 
+0

Merci de prendre le temps de nous aider KiwiBastard. J'ai corrigé le message d'erreur que le compilateur crache ci-dessus, désolé. Cela peut changer la nature de votre réponse, mais le #define est très utile. Je reçois toujours les avertissements du compilateur ci-dessus, même si j'utilise des crochets standard tout le long. Je peux obtenir la méthode "no" -myClass "trouvée" en spécifiant l'en-tête de myClass dans newClass. Mais "myClass" ne trouve pas dans le (s) protocole (s) "refuse de partir. Il compile et fonctionne mais l'avertissement du compilateur me rend anxieux au sujet de la stabilité de l'application ... Encore merci pour la réponse. –

Questions connexes