You’re working in Objective-C land trying to get a product out the door and into the Apple iTunes Store, right? (Don’t argue with me I’m just setting the stage.) You’re feeling the second cup of coffee seep into your bloodstream which creates a certain euphoric sensation as the last 3 times you mashed Cmd+B turned up no errors. Yes, that’s what’s happening in your copy of XCode right now. You then Cmd+Tilde to toggle the other XCode window active (Cmd+Tilde is a nifty Apple shortcut for switching active windows in the current app) and Cmd+B once again when a red flag on the play pops up in some code that had been just fine moments ago? What happened? Hi, I’m Cliff. You’re here because XCode got’cha and you’re not quite sure how/why/where. I’m here because I wanna list as many of these got’chas before I forget them.

Property accessor notation in Earlier SDKs
Here’s one weird gotcha that I just hit again for the first time. If you have a variable typed as a protocol and that protocol has a setter, which takes another protocol type defined then you may get an error when using dot notation in SDKs earlier than 3.0. That is a definition like this:

@protocol MyCoolAbstractType <NSObject>
-(void) setNetworkDataProvider:(id<MyNetworkDataProvider>)aNetworkDataProvider;
@end

…should be coded like this:

@protocol MyCoolAbstractType <NSObject>
@property (nonatomic, retain) id<MyNetworkDataProvider> networkDataProvider;
@end

…before you can do this:

id<MyCoolAbstractType> myObj = //create object from factory
myObj.networkDataProvider = [[MyConcreteNetworkDataProvider alloc] init];

Evidently the “Discover setter is a property” feature is something new Santa delivered with 3.0 and never told me about. Here I thought I had that toy from 2 years ago!

Unit Tests Can’t Be Signed
I added a unit test dependency to my “Application” target the other week in order to streamline my dev cycles. The idea was to ensure any changes I made to satisfy the integrated application bundle did not impact behaviors outlined in my test cases. (I use mini applications to perform my integration testing.) The problem here is that, even though this works well for simulator builds, an on-device build will fail as XCode attempts to sign your unit test target output. I haven’t discovered a work-around for this one yet so I’m gonna just punt and remove the test dependency from any targets meant to run on device.

I’ll trow up more as I find them…

I waste more time not knowing the details behind XCode. I’m playing with some basic image drawing code and trying to figure out why my custom UIView doesn’t appear on screen. Naturally I click the gutter in the drawRect method to set a break-point. XCode moonwalks right over the breakpoint each time! I try all different kinds of varaitions of my custom drawing, both overriding UIImageView and manually adding it to another view. Each time XCode does a hop-scotch over the drawRect breakpoint. I only notice that the break point turns orage when I run the program. I finally figure out that I had a type-o in a custom graphic file name causing it to appear like nothing was happening. Still XCode ignores my breakpoint.

Because I’ve seen this behavior before I now know my code is begin executed even though XCode doesn’t honor my breakpoint. What I really need to know is why does XCode sometimes ignore breakpoints? What is the significance of these orange breakpoints? As of now there’s nothing I can do to set the break-point except for checking the checkbox in the breakpoint manager dialog. Why does this happen? Why is my IDE clowning me?

*Update*
Found the answer here. In short, XCode sometimes gets its symbol references confused. To rememdy the problem you can either disable “Lazy Loading of Symbols” in the debug preferences or delete the file from XCode (just remove the reference not the actual file) and re-add it.

I’m getting more familiar with the tools and technology surrounding iPhone development but I still face challenges daily. Hi, my name’s Cliff. You’re here because a random Yahoo/Google search or cross-link from another site pulled you in by your chin hairs. (In the case of women reading you’re here because you’re trying to figure out where you husband/significant other spends all of his spare time.) Bear with me as I try to make sense of the tedium involved in XCode unit testing.

Not yer Daddy’s cup o’ Java!
For score and several years of Java development has seasoned me similar to a rotisserie side of pork spinning slowly over an open hearth. As a flavored piece of pig, I’ve come to expect certain things… from my IDE… from advertised test tools… from any form of modern development. For one, I don’t expect a ton of over head associated with adding a new test. Consequently, copying the Google tools for mac files into each project that wants to be agile is becoming painful. I’ve also come to expect… no demand a certain ability to easily decouple. Running things in isolation is key to true unit tests, not requiring the stars to line up is crucial. I’ve also grown used to the CLASSPATH. For those that only deal in XCode, Ruby, or Cocoa the CLASSPATH is the bane of all Java development allowing one to easily gain and/or dismally lose runtime visibility of entire libraries of supporting logic. Today I’m having trouble getting Objective-C class implementations to be visible without individually adding them. While that’s not too bad I found a classpathy work-around while playing with another open source project a while ago. This other project was setup with individual modules which made me very happy since it smells of modular reuse. It’s main module contained all of the supporting logic and could be embedded or reused in any client application. Writing tests that exercised anything from the project became a simple matter of adding that main module as a dependency of the test target.

My Dilemma
Because I started a project sans knowledge of how to properly decouple I have a bunch of classes tied to the default application build target in XCode. I tried to add this target’s output as a dependency of my test target as I did with the other project. Since the output is an executable application I believe it’s causing things not to work as expected. If you have any idea of a work-around that doesn’t involve adding each file loaded by the test to be manually added to both the application and the the test target then speak up.

Retribution *Ahem* Reimbursement
I’ve asked people to do my work for me plenty times before and I’m not ashamed to do it again. As your reward for being a faithful reader of my blog and committing occasional insight to my struggles you can expect silent but honorable mention as I speak to others on behalf of your contribution. Followup posts on this site to highlight your involvement in any way will be edited, reworded, and/or deleted prior to clearing moderation. (In all reality, I sincerely appreciate all comments and feedback. I don’t actually steal credit unless you request that I do and at the end of the day we’re all working towards a common goal… Don’t take nothing you read here seriously… it’s just jokes!)

Why don’t somebody fix this already? I think I finally got the latest XCode 3.1.2 to work with the latest Subversion 1.5 release. This was after downloading the latest 2.2 iPhone SDK. I scoured the web and found the best tip here. There’s another possible more automated solution here but because I don’t feel comfortable running a bash script I copied off of some web page (try it and you’ll cuss. Then you’ll see what I mean!) I went with the other approach. I’ll shorthand the steps I followed below because following the first link above, I think, misses some important files and doesn’t work correctly. The general idea is to copy your Subversion installed libraries (assuming you used the Collab.net bundle) into the place where XCode binds to.

From your home directory:
mkdir svn-bkup
sudo cp /usr/lib/libsvn_* svn-bkup
sudo cp /usr/lib/libapr-1.dylib svn-bkup
sudo cp /usr/lib/libaprutil-1.dylib svn-bkup

sudo cp /opt/subversion/lib/libapr-1.dylib /usr/lib
sudo cp /opt/subversion/lib/libaprutil-1.dylib /usr/lib
sudo cp /opt/subversion/lib/libsvn_* /usr/lib

[restart xcode]

That’s what I did and now it no longer complains “error 155021 this Subversion client is too old and stoopid to work with your shiny new svn checkout that’s just bananas!” Your error message may vary but the concept is the same.

This message is brought to you, in part, by the proud sponsors listed in the Hall of Aim.

The title may be slightly exaggerated but when you grow used to a tool like IntelliJ Idea you start to become spoiled by everything it gives you. First off refactoring support in Idea is second to NONE! Honestly, there are no front runners. When you code in Idea you can literally feel the text of the source code under your finger tips. Now goind from Idea to, say Eclipse isn’t too bad because Eclipse supports 98% of the refactorings that Idea has out of the box but it likes to torture you with dialog boxes. (I don’t like to be prompted or questioned when I know what I’m doing. If I ask to extract a method, or variable or rename something don’t give me some damned options just do what I ask!!!) Now going from Idea to something like visual C++.. phew!!! Talk about shell shock! Let’s just say it’s nice and toasty in the Idea house while somebody in the MSDN camp forgot to pay PPL. Ok now let’s move from Idea to XCode. Not as frigid as it was when we bolted butt-naked into Redmond with VS but still pretty darned cold. Why am I complaining?

Typical use case:
Dev guy writes a method. Dev guy later sees that he picked a dumb name for said method. (The method name should be a generic toggleView not a specific gotoTheVerySpecificUseCaseViewThatIThoughtOfAt10pmWhileIWasDrinkingPabstBeer) Now in Idea I use a hot-key on the method name type the new name and click run. (Nobody taps me on the shoulder to ask me if I’d like fries with that refactoring as they do in Eclipse land.) I just tried that fancy recipe in XCode and when I run I get an error. I didn’t even look at the details when GDB started to grind and slow the vent handling. I already knew from the last time I tried right-click and refactor a method name from the implementation. The refactorer doesn’t get those tough to reach spots. You know how when you ask you daughter to clean her room and she only gets the visible areas but you really wanted her to clean the back of that nasty closet? Or like when you buy one of those store brand toothbrushes with the labeling “Each! Compare to Reach toothbrush…” In other words, there were remnants left behind from the refactoring. This is completely unacceptable! As much as Apple pays attention to detail in their products I’d expect nothing less than perfection in their IDE! I don’t think this is an area where I’m misusing the tool either. refactor/rename should understand the Cocoa environment well enough to understand that I need IBOutlets referenced in nib files updated as well. I guarantee you that the folks at JetBrains would not have left this stone unturned.