Home/ Questions/Q 6957315
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T14:59:07+00:00

This one has me stumped. I’m writing an iPhone app that tracks bus schedules.

  • 0

This one has me stumped. I’m writing an iPhone app that tracks bus schedules. Users can bookmark their favorite bus stops so they can jump directly to them from the home screen. I manage the list of favorites in my AppDelegate class (unrelated code has been redacted):

@interface AppDelegate : NSObject <UIApplicationDelegate>
+ (BOOL) isInFavorites: (FavoriteStopData*) inStop;
@end

I have a view controller that presents the list of stops for a given bus route and lets users select one to see predicted bus arrival times for that stop in a new view (and maybe add the stop to their list of favorites):

@implementation RouteStopsViewController
- (void)tableView:(UITableView *)tableView didSelectRowAtIndexPath:(NSIndexPath *)indexPath {
    FavoriteStopData *stopData = [[FavoriteStopData alloc] init];
// ... set various properties in stopData from data in the selected cell
    FavoriteStopViewController *fvc = [[FavoriteStopViewController alloc] initWithNibName:@"FavoriteStopViewController" bundle:nil];
    fvc.stop = stopData;
    fvc.isBookmarked = [AppDelegate isInFavorites:stopData];
    [stopData release];
    [self.navigationController pushViewController:fvc animated:YES];
    [fvc release];
}
@end

The line 

fvc.isBookmarked = [AppDelegate isInFavorites:stopData];

gets two warnings:

“‘AppDelegate’ may not respond to +isInFavorites:”
“Passing argument 1 of ‘setIsBookmarked’ makes integer from pointer without a cast”

I can’t see any reason for Xcode to think ‘+isInFavorites:’ is undefined, yet it does. I’ve verified that these possible causes for the warning are not in fact the case:

  • ‘+isInFavorites:’ is declared in “AppDelegate.h” (as shown above)

  • “RouteStopsViewController.m” does #import “AppDelegate.h” (and “FavoriteStopData.h” and “FavoriteStopViewController.h”)

  • ‘isBookmarked’ is a public BOOL property on FavoriteStopViewController

  • The code is not being munged by some #define macro; when I preprocess “RouteStopsViewController.m”, this code is unchanged.

The code behaves correctly, but I REALLY don’t want to live with a warning that I must ignore every time the code compiles, and disabling this warning with some #pragma is a road I’d rather not take unless I have to.

I’ve tried renaming the method name, the variable names, using the method to set a local BOOL variable and then setting the property with that, using a conditional operator (x ? y : z) to make sure I’m passing a BOOL to the property … nothing works. That first warning never goes away.

Can anyone suggest why Xcode is giving me this warning?

This is with Xcode 4.2 (Build 4C199) and iOS 5 SDK running in the 5.0 iPhone Simulator on a MacBook Pro running Mac OS X 10.6.8 (Snow Leopard).

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Found it. Even makes perfect sense … now that I know exactly where to look.

    My project has two targets: Dev for the version I use to test new code, and App for the user-facing version. Each has its own AppDelegate class (and some other duplicates). Code specific to one target or the other goes into either the ./Dev/ or the ./App/ folder. Common code goes into other folders.

    Recently I promoted one Dev-specific class to be used in both targets … but hadn’t yet moved the files out of the Dev folder. This was my problematic RouteStopsViewController. My project was compiling the right “AppDelegate.m”, but Xcode was finding the ‘wrong’ (to my thinking) “AppDelegate.h” because it was looking first in the same folder as “RouteStopsViewController.m”.

    The fix was easy: move RouteStopsViewController out of the Dev-specific folder into one for code shared by both targets. Now Xcode uses the “AppDelegate.m” file it’s compiling to find the matching “AppDelegate.h”.

    I knew at the time I should move that RouteStopsViewController class when I decided to reuse it in the App target, I just didn’t get around to it. When it comes to writing code, trust your nose. If it smells funny, it very probably is.

    • 0