views:

2631

answers:

3

I have myClass instantiated by my appDelegate, I have another class, newClass instantiated by myClass. From the newClass instance, I want to access a property in the myClass instance that created it. I have done this by:

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

This works, I can actually get the property but I get this warning from 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)

The newClass property has been correctly declared in the .h and .m files, it's properties have been set and it has been synthesized.

It compiles and runs and I can actually get the property's value.

Should I ignore the warning in Xcode?

Is there a better way to access the myClass instance's property?

A: 

I think at compile time Xcode can't make the leap from properties and normal Objective-C. It can't find the property so will just assume you know what you are doing and fill in the blanks. At run-time things are obviously ok.

Try this instead:

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

BTW so you don't have code like this littered throughout you own code I usually do a #define in the header of the app delegate:

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

So then in the code I can just go:

[[APPDELEGATE myClass] property];
KiwiBastard
Thanks you for taking the time to help out KiwiBastard. I've corrected the error message the compiler spits out above, sorry. That may change the nature of your answer, but the #define is quite useful. I still get the above compiler warnings, even if I use standard square brackets all the way. I can get the "no "-myClass" method found" to go away by specifying the header of myClass in newClass. But ""myClass" not found in protocol(s)" refuses to go away. It compiles and works but the compiler warning is making me antsy about the app's stability... Again thanks for the answer.
DK Crame
+3  A: 

Look at the documentation for -[UIApplication delegate]. Note that it has a return type of:

id <UIApplicationDelegate>

Therefore, all you know about the returned object is that it conforms to this protocol. It is nothing less than a leap of faith to then assume that the delegate responds to the -myClass message, and not one the compiler is willing to make.

You could hack it slightly to work like so:

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

But it would be bad practice. Instead, I suggest you make your application delegate a singleton so you can do:

[[[MyAppDelegateClass sharedApplicationDelegate] myClass] property]
Mike Abdullah
Thank you very much Mike Abdullah. I only wanted one particular instance variable. I finally settled on the singleton solution as you suggested.
DK Crame
Sorry, why exactly is that bad practice? That sounds like the sort of thing that I would do :p
AriX
To begin with, typecasting is generally a bad sign. In this case it makes your code more brittle by assuming that the app delegate will *always* of that particular class. As your application develops, that may not be true, particularly if you ever get into things like unit testing.
Mike Abdullah
A: 

@DK Crame

Is there a way to get rid of these messages ? I use the appdelegate methods and classes in almost all of my child classes. I also have tried to above , but no luck.

Thanks in advance,

Patrick

Pythic