iOS warning balloons- warning: 'XXXViewController' may not respond to XXX

[mlecho]

hi, i am new to objective c, but have a question. I am following a JSON framework tutorial...all is working fine, but i am getting this annoying yellow warning in my app. I wrote a method to simply return a value. My app is working thus far in my development, but this yellow warning balloon is bothering me. Yes, it's correct that the method is ONLY in my implementation. Do i have to stick it in the header as well??? It's not meant to be a public method.

Here's the method(s):

- (id) getData:(NSString *)url
{
	NSString *jsonString = [self getJsonString:url];
	//YELLLOW BALLOON HERE THAT READS- warning: 'JSONTestViewController' may not respond to '-getJsonString:'
	SBJSON *jsonParser = [SBJSON new];
	return [jsonParser objectWithString:jsonString error:NULL];
}

- (NSString *)getJsonString:(NSString *)url
{
	NSURLRequest *urlRequest = [NSURLRequest requestWithURL:  [NSURL URLWithString:url] ];
	
	NSURLResponse *response;
	NSError *error;
	
	NSData *returnData = [NSURLConnection sendSynchronousRequest:urlRequest
											   returningResponse:&response
														   error:&error];
	
	return [[NSString alloc] initWithData:returnData
								 encoding:NSUTF8StringEncoding];
}

 

[wlh99]

Either put it in the header file(the correct fix), or make sure the implementation is in the .m file before where the method is called.

The if the compiler doesn't know about the method when it compiles the code where the method is called then it will throw a warning.

 

[mlecho]

ok ok ok...into the header then. It's so bad to be a lazy programmer...i know

 

[PhoneyDeveloper]

If you wish to have a method that's not public then the usual strategy is to use a category for this that goes in your .m file.

@interface MyClassName (private)
- (id) getData:(NSString *)url;
@end

Put that at the top of your .m file outside the @implementation for MyClassName. This gives you both the ability for the compiler to see your prototypes and privacy to prevent these prototypes from being seen in your header file.

 

[dejo]

If you really want a private method, don't put it in the header because then you are declaring it public and giving other classes permission to access it. But since Objective-C doesn't support true private methods, you might want to use categories to achieve something similar. Along the lines of the following in your .m file:

@interface MyClassName (PrivateMethods)

- (void)privateMethod1;
- (void)privateMethod2:(id)sender;
...
@end

@implementation MyClassName
...

 

[Luke Redpath]

There's no need to declare a "Private" (or any other named) category; simply use a class extension (anonymous category) and implement your private methods in the main @implementation block:

@interface MyClass()
- (void)myPrivateMethod;
@end

@implementation MyClass

- (void)somePublicMethod() {
}

#pragma mark -
#pragma mark Private

- (void)myPrivateMethod;
{
}

@end

This is the way Apple recommends declaring private methods. The pragma isn't necessary but helps separate your private methods visually in the class navigator drop-down. Doing it this way means the compiler can check that all of the private methods have been implemented.

 

[dejo]

There's no need to declare a "Private" (or any other named) category;

No need, true. But it doesn't hurt and makes it more obvious what you're doing.

 

[acsouzad]

No need, true. But it doesn't hurt and makes it more obvious what you're doing.

It might hurt actually. According to Apple it decreases the number of compiler checks, which increases the chances of coming across a run time error.

 

[dejo]

It might hurt actually.

I was referring to the hurt of a named category vs. anonymous category and not simply the use of class extensions.