SPViewController+Transparency extension problem

membersheep

I was using shilo's extension SPViewController+Transparency ( http://goo.gl/DKH76B ) with Sparrow 2.0.1 (with cocoapods), and everything was working fine. Now I'm trying to use Sparrow 2.1, then I eliminated the sparrow entry from my podfile, re-installed my pods and imported Sparrow 2.1 framework. Everything is compiling with no problems but I keep getting this linking error with the extension:

Undefined symbols for architecture armv7:
"_OBJC_IVAR_$_SPViewController._statsDisplay", referenced from:
-[SPViewController(Transparency) statsDisplay] in SPStage+Transparency.o
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The problem doesn't seem to be in the extension source code to me because nothing changed from 2.0.1 I guess...
any ideas?

edit:
-the SPStage+Transparency.m is in my "Compile Sources" list in build phases, in fact the SPStage+Transparency.o seems to be created.
-the project builds correctly if I remove the extension.
-if I comment the declaration

@interface SPViewController ()
{
// SPStatsDisplay *_statsDisplay;
}
@end

and substitute in code with self.statsDisplay it builds but crashes.
This is the line that prevents the linking

@implementation SPViewController (Transparency)

- (SPStatsDisplay *)statsDisplay
{
    return _statsDisplay;
}

@end

anyone can guess why?

PARTIALLY SOLVED:
I made it work by commenting all the statsDisplay related code, but I'm still trying to understand why.

thanks

Daniel

Hm, very odd. You're right, that doesn't sound like a problem with the extension, but with the Sparrow project.

But that error only starts to appear as soon as you add that extension, is that right?

Probably I'm stating the obvious, but have you cleared all Xcode caches (e.g. in Windows / Organizer / Projects)? Maybe there's some left-over from the old version ...?

membersheep

Yeah, I tried that too. It only appears when I add the extension and when the statsDisplay code is not commented. I don't need the stats for now so I can live with that part commented, it just seemed a strange error and since I don't know very well how categories are compiled and linked, it made me curious.

Daniel

That's extremely odd, yes — I can't see any logical connection between the stats display and that extension ...!

Shilo

I know this problem very well. This issue has happened with quite a few of my extensions, I believe ever since Sparrow was converted to ".framework". The issue is due to attempting to expose an "already-existing" variable in a category, which no longer works. Previously, this worked fine, allowing me to gain access to private variables and avoid "Key-Value Coding". Also in most cases, Key-Value Coding won't be useful because it only allows retrieval of objective-c objects only.

I guess the true problem is that Sparrow lacks a lot of customization support without digging directly into the source. There are many times when my extensions/features require access to private variables. Lots of times I would kill to have a private variable made protected, or a simple property. But, I still love Sparrow! No better alternative.

Either way, I will test it and give you a fix shortly. In this situation, Key-Value Coding should do the trick.

Shilo

The fix:

@implementation SPViewController (Transparency)

- (SPStatsDisplay *)statsDisplay
{
    return [self valueForKey:@"_statsDisplay"];
}

@end

You can find the updated class (which includes the updated headers also), here:
https://gist.github.com/Shilo/5794447

membersheep

Wonderful! Thank you! I guessed I could fix it with one of those objective-c weird tricks but I was trying to find a more elegant solution.
I still don't have clear in my mind why this fix was needed, it worked with a static library but not with a framework?!

edit: It works!

Shilo

I still don't have clear in my mind why this fix was needed, it worked with a static library but not with a framework?!

Wish I knew the answer myself. I haven't done any research on it. All I know is that switching to a framework broke all that loveable code.

Daniel

Thanks for providing that fix, Shilo! I didn't know, either, that the framework version could have such a side effect. Bummer. 🙁

And yeah, I totally know what you mean about the extensibility ... I get this complain a lot in Starling, because there, you can't even use any workarounds to get to those private variables *g*.