Downgrade your iPhone DFU mode

My iPhone crapped out on me this weekend. I went to use it and the screen wouldn’t show at all. I loaded iTunes which was able to recognize it and offer to restore it to factory. Word of advice, iTunes is very sneaky! I didn’t realize that the factory restore it offered came with a complimentary upgrade to OS 3.1.2! It became apparent after I went to use the device and swiped right revealing the new spotlight search. Crap! I needed to keep it on 2.2 because I need to verify 2.2 compatibility. No worries, I’l just down grade when I get to the office. I then realized that I couldn’t build and run on device using XCode. I was getting “No Provisioned device connected” errors. I got concerned thinking I had to go through the whole re-provisioning my device hassle. Then I realized the “use for development” button in XCode. One thing lead to another then I finally realized all of the ugly truths about iPhone development.

1. OS 3.1.2 only accepts builds from XCode with iPhone SDK 3.1.2.
2. The iPhone SDK 3.1.2 only installs on OSX 10.6 (Snow Leopard)
3. Apple no longer offers any iPhone OS earlier than 3.1.2 on its website.
4. If you are lucky enough to find a lingering copy of iPhone OS 3.0 or earlier, you cannot roll back from 3.1.2 (…easily) due to baseband errors.
5. DFU mode is not easy to do or understand.
6. You will likely spend the good part of a couple of days trying to recover from an unintentional upgrade as your first 5-7 rollbacks will leave you with misc errors.

The simple answer is that you cannot downgrade the OS without using DFU mode. DFU stands for Device Firmware Upgrade and is a secret mode that Apple doesn’t want you to know about. You have to use something similar to the old Nintendo Contra cheat (you remember up, up, down, down, left, right, left, right, b, a…) to enable it. I’ve tried it a couple of times so far and realized that you probably should have a completely installed OS before trying it. My second attempt (after a fresh iTunes restore) left me with an error and I’m hoping the third time is a charm. Here goes nothing…

XCode orange breakpoints???

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?

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.

CoverStory on IPhone projects

I really, really, really don’t care about test coverage when I develop because it’s one of those things you get for free when you follow the right practices. I always thought projects like Clover and Cobertura were a waste of time. However I recently started dreaming up an interesting use case for these kind of tools. Help me, if you will, get CoverStory (a test coverage tool for ObjC) up and running so I can prove myself wrong. I’ve followed the [sparse] documentation and steps on the CoverStory home site. There’s a section on including an alternate, fat libgcov.a file that confused me. Not knowing what path to what file or where to set the path I stumbled on a way of satisfying the “no such file for -lgcov” error by dragging/dropping the fat libgcov.a file into my project. Now when I build I get the .gcno files but no .gcna files and Coverstory won’t report coverage. CoverStorySettings

iPhone Boot Camp

Platoon… Attention! Forward… March! About… Face! Platoon… Halt! Parade Rest!… At ease…

Many moons ago I attended boot camp and that’s kinda the jest of it. Sure there were some rifles fired here and some push ups done there. I believe there was even a drill sergeant or two but the above was the general format. Hi, I’m Cliff. You’re probably here because you’re wondering how to fix that EmptyStackException in your XML transform. Or maybe you’re trying to run Blackberry compilers on your MacPro and you keep getting verification errors. Or maybe you just Googled my name and landed here by chance. Whatever the catalyst the net result will be pure edutainment. (Yes edutainment is a “Can’t See Nothing But the Source” exclusive! Remember where you heard it first!) If you are not completely edutained then you’ll probably feel edu-pain.

Back to Boot Camp. That’s where I was privileged to be this past week. Not the original left-right-left boot camp, but a different kind. This boot camp was lead by none other than Aaron Hillegass. He wasn’t as loud as my former Drill sergeant’s Morris, Decker, and Perez (BTW, they would just love to hear me address them without their demanded “Drill Sergeant” prefix), but he did give a lot of quality info on all things Mac and iPhone development related. Tag teaming with Jaun Pablo, Aaron gave a five day hands on shop which involved responding to touch events, in depth networking, iPhone multi-media and more. The second half of the course was all about software development for the Mac desktop. We learned how to build installers, how to auto upgrade via app-casts, how to build quick look and spotlight plugins, and how to overlay Quartz graphics on an Open GL context. Then there was my favorite topic, unit testing. I found out that Apple released support for iPhone unit testing behind my back with their 2.2 SDK release. I’d love to write more about the topic but I have a lot of catching up to do. Shotz out to Aaron and Juan Pablo! Drop a line on whatever and we’ll speak on it.

iPhony Frameworks

So I’m writin’ all kinds of Objective-C code, right? And I’m finally in my element because I got Google Tools For Mac doin’ the SenTest thing, right? I even figured out how to include modules using project relative paths. That’s when my trouble started. Y’see, I thought frameworks were no different than modules. Of course they’re different or else they wouldn’t be called frameworks! Still, I blurred the line between the two. So then I’m writing all these gnarly tests using OCMock. Remember OCMock? I complained on the forums about adding it to an iPhone project. then I finally found a hack to get it to run in my iPhone tests. Then the whole module thing started to make me feel warm and fuzzy inside so I thought I had a better approach. At any rate, I tried the same approach with Hamcrest, a tool advertised on the OCMock home page. I couldn’t get it to work. Finally, it dawned on me! You can’t add frameworks to iPhone projects! [Honestly it didn’t dawn on me, I had to be told then re-told by someone who knows waaay more about iPhone stuff than me.]

The point is that Frameworks in XCode iPhone projects don’t work like modules. With a module, you can just drag/drop the module file into your project, set its dependencies in your target, build and then you’re off and running. Frameworks are different. Frameworks have to exist (to the best of my knowledge and until someone who knows stuff tells me some new stuff) under /Library/Frameworks in order for SenTest test cases to use them. Frameworks can not be used at all during run time in an iPhone project. I don’t even think they’ll run in the Simulator which means no debugging unit test code, which means you better write some very fine grained unit tests which turns out to be necessary anyhow. That’s the point. You can’t run Framework code in an iPhone project but you can run it in a GTMSenTestCase as part of the build (not build/go process). If anybody knows better speak up now or I’ll forever hold out the peace sign.

Subversion 1.5 and XCode 3.1.2

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 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 Leg Bone’s connected to the…???

No matter how many times I tell my four year old back, up she continues to play kiss the door knob. No matter how many times I warn my 9 year old to thumb-tack her book-bag to her spine in the morning, she continues to show up at school sans knapsack. I somehow believe my kids enjoy hard times, appreciate the torture of incinerating your appendages on the hot oven door, and outright live for the moment somebody will come crashing through the doorway embedding the door handle in a young forehead. Then I realize there are certain things that they won’t include in the text books… certain things they won’t teach in class or during an online tutorial. These are the things you have to find out by smashing your nose, breaking your arm, and making an absolute fool of yourself. It’s the first step in agile development is it not? It’s the red before the green-refactor, isn’t it? It is amazing to watch the test driven antics in somebody less than half your age.

Before I allow George Killian to seep deep enough into my blood stream to rip the original intention out of my cerebrum let me explain what I just learned. Apple’s Interface Builder != Springframework. Sure it tastes like apple pie but there are no apples in it. Here’s the deal. You would think (or you would if you wore an argyle sweater like me) that wiring a UIImageView to your controller would be sufficient enough to make that same UIImageView available when you loaded the controller from a nib file in the main bundle wouldn’t you? [Yes you would because you’re me in this hodge-podge example… just play along! I don’t care if you never heard of a nib file. Nod your head and say uh-huh…] Calling initFromNib on your controller will read in the nib file and eventually perform the internal connections/plumbing but your next statement will be in for a surprise if it attempts to inspect or dig values out of the controller that are connected to other things with Interface Builder’s connect the dots magic. Here’s what I mean. Create an arbitrary UIController named LegBone and give it a HipBone IBOutlet property. (Create a HipBone class in your project.) Create a nib file, open it in Interface Builder and set it’s FilesOwner to LegBone. Drag and drop an object from the library into the nib file’s main window and then connect the legbone to the hip bone. In your app delegate, instantiate the LegBone using the nib file and declare a local variable of type hip-bone while setting it equal to the property from LegBone on the following line. Run all of this in the debugger and watch as XCode reports 0x0 (or null, or is it nil? What’s the doggone difference and can we settle on a universal nomenclature for a value that doesn’t exist across all programming languages???!!!) when you step to and hover over the LegBone.hipbone property assignment. It should look roughly like this (not compiled or cross checked due to laziness):

@interface LegBone : UIViewController
   IBOutlet *HipBone hipbone;

@property (nonatomic, retain) IBOutlet *HipBone hipbone;

@implementation MyAppDelegate

- (void)applicationDidFinishLaunching:(UIApplication *)application {
	LegBone *myLeg  = [[LegBone alloc] 
								 initWithNibName:@"LegBone" bundle:[NSBundle mainBundle]];
        HipBone *hip = [myLeg.hipBone];
        NSLog(@"My hip is %@", hip);

Of course after catching the problem the obvious thing to do here is to instantiate the hip in your delegate and set it on the legbone since Cocoa is too lazy/slow/unwilling to do it for you. That brings me to my next surprise. I caught this immediately afterwards but it could have easily been one of those 2 day investigations that check everything but the obvious. Setting the hip bone programmatically without clearing the connect-the-dots magic in InYourFace Buildher will only be undone by the runtime when it finally gets around to connecting your dots during runtime. In other words, say you have this:

@implementation MyAppDelegate

- (void)applicationDidFinishLaunching:(UIApplication *)application {
	LegBone *myLeg  = [[LegBone alloc] 
								 initWithNibName:@"LegBone" bundle:[NSBundle mainBundle]];
        HipBone *hip = [[HipBone alloc] init];
        myLeg.hipBone = hip;
        NSLog(@"My hip is %@", hip);

And pretend you forgot to remove the HipBone object in Innerplace Biller. You’ll fix the nil pointer in the app delegate but then inside LegBone you will be talking to a different hip. For a beginner like myself, trial and error will likely never show the core problem. You have to know what to look for. You have to know that wiring is performed at runtime and possibly at a later stage or in an entirely different method. It’s like Dr. House says, “When something doesn’t make sense, one of your assumptions is wrong.” In this case you would assume that initializing a controller from a pre-wired nib will instantiate all of your nib file’s internal objects and prime all of the setters. You would assume that these things happen before control returns to the next statement as it would if you were loading a Spring beand factory and asking for a bean. That’s all for now. I’m going night-night.